Re: GnomeGoal for 3.8: DesktopFileKeywords
Le 15/11/2012 09:19, Henrique Ferreiro a écrit : Matching on any of the languages installed in the desktop would probably be the most sensible way to do it. Hi, Not sure matching in other languages, including english, is a good idea. The typical $locale user is searching for a word in his language, likely having no clue that english has a similar looking word with totally different meaning ... the net result is that he will get listed something that's not remotely relevant to what he was looking for without understanding why. You need to go quite some way to figure ok, that work might mean something else in some language I don't know and the system is trying to help me... Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeGoal for 3.8: DesktopFileKeywords
Le 15/11/2012 19:43, Alan Cox a écrit : That very phrase shows some ignorance of language use in much of the world Right, that was a simplification, I guess the key point would be to try to not search in a language the user doesn't know... Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is File Roller 3.6.0 a broken version?
Le 21/10/2012 22:01, Bastien Nocera a écrit : I should note that they're particularly bad at shipping past the .0 releases, so you might need to prod them in that direction. Hey, That statement is not really accurate, while we had some issues in the past Ubuntu (I'm sure we can find some updates missing at some points in any distribution), we does most of the updates to .1, .2 etc, especially in LTS cycles. Our schedule doesn't align so nicely with the GNOME one recently and .1 comes out during our release freeze so we have to ship it as updates rather than as part of the release though For the record on that file-roller update: - we reported several of the issues mentioned upstream - we backported a number of the fixes for those issues in our package before upstream rolled new tarballs https://launchpad.net/ubuntu/+source/file-roller/3.6.0-0ubuntu2 https://launchpad.net/ubuntu/+source/file-roller/3.6.0-0ubuntu3 - file-roller 3.6.1.1 was uploaded to quantal updates before Bastien wrote that email stating that we don't do updates: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1069443 Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is File Roller 3.6.0 a broken version?
Le 22/10/2012 10:09, Bastien Nocera a écrit : I've had to close numbers of bugs in Totem, gnome-control-center, and gnome-bluetooth over the past number of years because you barely did updates past the .0 releases. I'm glad you changed that. Just for the record, taking gnome-control-center as an example here is the summary of the versions we ship: https://launchpad.net/ubuntu/+source/gnome-control-center Since 2010 we shipped the updated gnome-control-center stable-versions up to the current one in almost all series (the only exception is Oneiric where we stopped at .2 where there is a .3 update out) I'm glad that you appreciate the efforts ;-) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is File Roller 3.6.0 a broken version?
Le 22/10/2012 10:24, Maciej Piechotka a écrit : Any chances of updating libgee? I don't think I saw any bugs yet caused by it but the Ubuntu versions tend to be much older then current stable in given branch. Hey, We have 0.8.0 which was updated the day after it was released: https://launchpad.net/ubuntu/+source/libgee-0.8 0.8.1 is out for a week but Ubuntu has been hard frozen for release ... is that what you qualify much older than current stable? (If you want to follow up on that maybe better to do it off the list, discussing what specific versions are available in what distro doesn't seem like an interesting topic for d-d-l) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 11:00, Bastien Nocera a écrit : I intend on making systemd a hard requirement Hey Bastien, Was there any consideration to define those interface as standard freedesktop interfaces to let GNOME work on any system implementing those? Some distributions (Debian, Ubuntu, ...) don't use nor plan to use systemd, your decision basically means those options for those distributions: - keep the current version of gnome-settings-daemon - distro patch/fork g-s-d to keep supporting non systemd systems - stop shipping GNOME Which one do you envision distributions opting for there? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 15:23, Bastien Nocera a écrit : If you want to provide compatible interfaces to systemd without using systemd, then you'll need to engage with the systemd developers to make sure that APIs are suitable for your implementation. No, I don't plan to do that work either so I will take from it that GNOME is not interested by being distributed on e.g Ubuntu anymore. I will take note about that and it's a topic we will discuss at next UDS, let's see if the GNOME remix effort who started recently has people motivated by doing that work, otherwise I will suggest we stop making GNOME available since Ubuntu doesn't have the requirements to run 3.8... Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Le 19/10/2012 15:41, Matthias Clasen a écrit : I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? The discussion went this way: 1: g-s-d will drop non systemd support 2: could we define standard interface that are up to the distributor to implement rather than depends on systemd? an hard depends would mean those choices for non systemd distributors: list of options I could see 1: no, I don't intend to spend any time on that, if you don't want to use systemd you need to work with systemd upstream 2: ok, well I guess we need to think what to do then, but it's limiting our options to get GNOME shipped I'm not sure how unproductive it has been, it's merely stating intends and sharing concerns... What I'm hoping to achieve? I guess letting know GNOME, as a project, know in what position this choice put some of the distributors and what might be the outcome. It's sharing information and communicating ... is there any issue with that? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.6 Blocker Report
Le 21/08/2012 11:28, Andre Klapper a écrit : The blocker list below is not necessarily complete. Feedback, updates, help from packagers, developers, maintainers, contributors, etc. is welcome. Hey Andre, Seeing the number of port to gstreamer 1.0 and seeing that's it feature freeze and gstreamer 1.0 is still not out, would it make sense to reconsider the choice of gstreamer version for 3.6? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Support both gstreamer 0.10 and 1.0 for GNOME 3.6?
Le 29/07/2012 04:58, Olav Vitters a écrit : What of that is on the Ubuntu cd? sushi is the only source listed there not on the Ubuntu CD I think in summary you say the following: - Not tested yet by wide audience meaning: development versions of distros well, you can reverse the question, who tested it. Does it represent a small subset of a big one of the GNOME userbase? - Don't want gstreamer 0.10 and 1.0 on one cd meaning: fine if some stuff still uses 0.10, as long as it is not on the cd. I don't see something like Sushi being a problem. right, Ubuntu as a distributor doesn't want to have to ship and support two stacks of gstreamer packages on our default installation, it would probably be better for GNOME as well to use only one. You forgot one the availability of codecs distributors and users rely on for gstreamer1 Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Support both gstreamer 0.10 and 1.0 for GNOME 3.6?
Le 29/07/2012 12:11, Matthias Clasen a écrit : Can you add anything that is on your live cd and uses gstreamer to this list (if it isn't there yet) ? https://live.gnome.org/GnomeGoals/PortToGstreamer1 Editing the wiki doesn't seem to work for me at the moment I get a TextCha: Wrong answer! Go back and try again... every time I try to commit the changes I will try again later Things I listed: bluez libreoffice gnome-media (gnome-sound-recorder is still useful) libgnome-media-profiles (gnome-media build-depends on it) libdmapsharing (rhythmbox uses it) pidgin (empathy uses libpurple for non jabber accounts) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Support both gstreamer 0.10 and 1.0 for GNOME 3.6?
Hey, I've been talking to some people at GUADEC about the gstreamer 0.10 to 1.0 transition and the issues it creates (especially for distributors), one of the outcome of those discussions is that it might be a good idea to ease the transition by supporting both versions for one cycle ... so here we are, I'm emailing d-d-l to do that suggestion. During previous discussions on IRC some maintainers pointed that the api changes were pretty minimal, which means it should be easy enough to ifdef both for one version. Some issues raised with the transition: - gstreamer 1.0 has not been released yet - gstreamer 1.0 didn't get lot of user testing yet - it might end up that some components rely on gstreamer 1.0 in GNOME 3.6 and some 0.10, distributors might not want to ship,support 2 gstreamer stacks though - some codecs haven't been ported yet (the fluendo mp3 one for example) What do you think about doing a smooth transition by supporting both for a cycle? -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Support both gstreamer 0.10 and 1.0 for GNOME 3.6?
Le 28/07/2012 14:15, Bastien Nocera a écrit : Hello Sébastien, Hey Bastien, The API changes are minimal, but: - The build changes are rather bigger, and adding options means more likely to break - The code will get harder to understand by the sheer number of tiny API changes, see for example: http://git.gnome.org/browse/totem/commit/?id=64f8b8e163cd804240a1427205c4bedb39793e59 Ok, fair enough, it's true that supporting 2 versions is complicating the code and making testing harder, it also makes also harder to deal with bug reports. Some issues raised with the transition: - gstreamer 1.0 has not been released yet There are development releases that date back a couple of weeks, and there will be more releases before GNOME 3.6 is out. Right, those are still beta versions and the schedule tight (it might end up gstreamer 1.0 gets delayed a bit longer for whatever reason) - gstreamer 1.0 didn't get lot of user testing yet It did, quite a bit, as it's been in development for a number of years, and will do even more in the coming months. Well devel serie testing and end user testing is not the same thing. In practice very few ported applications reached distribution users yet which means in fact the feedback has been pretty limited. - it might end up that some components rely on gstreamer 1.0 in GNOME 3.6 and some 0.10, distributors might not want to ship,support 2 gstreamer stacks though In the GNOME core modules, there's Totem, sound-juicer, and Cheese, all of which have been ported to GStreamer 1.0, the porting of small users (Evolution's audio preview) and related (gnome-control-center using libcheese). The only big user is Empathy, and that's the only blocker really. In Fedora, we should have all the users on the live CD ported and packaged up shortly after GUADEC. Great to see progresses here. Do you know what's the status of the rhythmbox port and when it's likely to land? There are a few ones I didn't see listed and that don't seem ported yet: shotwell (does it needs vala to get bindings for gstreamer 1 first?), brasero, sushi, (libreoffice? seems to be in the gst0.10 rdepends list on Ubuntu but I didn't check why) - some codecs haven't been ported yet (the fluendo mp3 one for example) Chicken and egg. Fluendo won't port the codecs if nobody uses GStreamer 1.0. And if you won't use GStreamer 1.0 because the Fluendo codecs haven't been ported... I'm not sure what Fluendo's schedule is but they said they were looking at porting their codecs, next cycle would probably be a safer target for those who need those though I guess. Backtracking now would probably be more costly, but might be necessary if Empathy cannot be ported. Ok, as long as one version only is used by the core desktop I think it's a fair decision for GNOME to go with the new version. Distributors might have extra external constrains (shipping things out of the GNOME core, extra codecs, ...) and a more conservative approach to updates (and the potential regressions due to those) but that's a downstream issue at this point. Just as a note, Ubuntu will likely stay on gst0.10 for its default installation still this cycle so we will hold back on updates for components that drop support for that version, if as an upstream maintainer you have issues with that please talk to us. -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 12:56, Bastien Nocera a écrit : So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Well old behaviour back, you will still not get GDK_SCROLL_UP,DOWN events so any code checking for those will need updating. Speaking about trivial it's not really, it took 5 patches to nautilus, one of the patches created a segfault and there are still issues unsorted after that. Grepping though GNOME sources there is at least 15 sources that will need to be patched, that also doesn't include out of GNOME softwares... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 13:33, Sebastien Bacher a écrit : Grepping though GNOME sources there is at least 15 sources Ryan came with a list built from precise gtk3 rdepends which includes those components: abiword anjuta-extras brasero cheese epiphany-browser eog evince evolution gedit glade gdm ghex gnome-applets gnome-control-center gnome-documents gnome-panel gnome-utils goocanvas gtk-vnc gucharmap libwnck nautilus notification-daemon rhythmbox seahorse totem vte webkit There is about the same number of source out of GNOME, including sources like cairo-dock, bluefish, libreoffice, ... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Le 16/03/2012 13:50, Patryk Zawadzki a écrit : Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? Well then maybe there is a bug in GTK with scale widgets, sliders stopped reacting to up,down scroll events i.e in the control center sound panel... -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
Hi everyone, GTK 3.3.18 and smooth scrolling landing created quite some issues which seems to have been mostly unnoticed, unaddressed so far, since the hard freeze for GNOME 3.4 is next week I'm bringing the topic there. Some of the details there might be wrong and I'm happy to be corrected, it's just my understanding of the changes * widgets need to opt-in for scroll events (GDK_SCROLL_MASK), that makes scrolling stop working in applications using custom widgets (example: http://git.gnome.org/browse/nautilus/commit/?id=04116ab2876412445c788091be07d7f7321a4a94) * if you are on xserver 1.12 with xinput 2.2 your application stop receiving GDK_SCROLL_DOWN and GDK_SCROLL_UP events, but receive GDK_SCROLL_SMOOTH with an increment instead that change seems to create quite some issue, it breaks for example mouse wheel scrolling over sound sliders in the control center, or scrolling in nautilus compact view Grepping around in my work tree I see there are quite a lot of GNOME components using GDK_SCROLL_UP,DOWN, I guess those will stop working as they should. Nautilus fixed a such issue in http://git.gnome.org/browse/nautilus/commit/?id=1a76e044a2c9b834d00c4ea30f1e3af3321d8cdd It's likely that other applications will need to add extra cases to handle the new way I think that's an issue we should look at addressing before 3.4, either by doing some compat work in GTK (i.e keep emiting the scroll up down events as well as the smooth ones if possible) or by patching the applications, the rdepends list is likely not trivial though... Thoughts? -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.4 Blocker Report
Le 09/03/2012 12:50, Andre Klapper a écrit : This is a list of potential release blockers plus some should-fix tickets according to yesterday's release team meeting. Hey, I'm not sure that's the right medium for that but I would like to point those gtk issues as potential would be nice to address for 3.4, maybe that can motivate some people to help fixing seem ;-) * GTK smooth scrolling not being optimized: https://bugzilla.gnome.org/show_bug.cgi?id=672091 in practice it makes scrolling generate lot of events and redraw and turns smooth scrolling to slow scrolling in some way, not sure it's a blocker but it's something quite some users noticed and which reflects on how responsive the system feels * GTK missing enter events on touch devices The bug has a testcase and a video, seems only the first enter event is generated, that leads to issue in menus (no highlighting) after the first entry for example https://bugzilla.gnome.org/show_bug.cgi?id=672009 Those issues are probably xserver 1.12 specific, but most distro to release with GNOME 3.4 should have that version... Thanks for considering, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 23:08, Lennart Poettering a écrit : You know, your complaining would be a bit more believable if Google wouldn't find this for us: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit So, the problem set has been known for a while, a number of Canonical desktop team members have been subscribed to that page, the documentation for the interfaces is all available, some code has already been written by Canonical. So I really don't see what went wrong here, except maybe that Canonical's internal communication didn't work out so well? Hi, Why do you guys insist in making that a Canonical,Ubuntu issue? I've replied previously that it's not an issue for us and I will tell it again: the change is not really a surprise and not an issue for Ubuntu since we are staying on GNOME 3.2 this cycle and we will have solutions in place before we upgrade next cycle. That said I wrote the emails on that list as a GNOME contributor (would it help to not focus on Ubuntu if I was written using my debian email rather than the Ubuntu one?) because I think GNOME as a project could do better. This example might also not be problematic but who knows about other changes that will happen in the next years, it would still help if GNOME was settling on an improved communication for the platform requirements. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: systemd as external dependency]
The email has been sent on the gnome desktop-devel-list today: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html Not sure if people there read GNOME list but since the topic is interesting for the distribution I figured I would just share the info Cheers, Sebastien Bacher ---BeginMessage--- Heya, I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. Currently the interfacing between GNOME and systemd is minimal. Bastien has been implementing a UI for changing the host name via a configuration UI in the control center which uses a tiny mechanism daemon included in systemd as backend. GLib already exposes g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose only implementation I know right now is in systemd. In the future I expect more interfacing with GNOME however, and I'd thus like to see the discussion regarding acceptance as blessed dependency started early. In the long run I expect the following additional interfaces used by GNOME or one of its components: - I am working on two more mechanisms generalizing control of the system locale and system clock/timezone for use in the control center and by other UIs. - gdm will interface with the new CK-replacing code I am working on. http://lwn.net/Articles/441328/ - gnome-session will be augmented by a per-user systemd instace, leveraging the benefits that systemd gives you for system startup also for session startup. - Later on I hope that we can use per-application cgroups to create reliable mapping between desktop files and processes. (i.e. place each app in a cgroup and name it after the .desktop file), integrated into the systemd cgroup hierarchy, so that this can be used for g-s and other UIs to relate desktop files to processes. And I expect a couple of more interfacing points, however things get more and more into vaporware areas with those. With these interfaces I hope to bring the speed improvements we are providing for the system also to the session. Also it brings a ton of new user-visible features with it, like automatic multiseat, or the ability to change the system locale. systemd is Linux-only. That means if we still care for those non-Linux platforms replacements have to be written. In case of the timezone/time/locale/hostname mechanisms this should be relatively easy as we kept the D-Bus interface very much independent from systemd, and they are easy to reimplement. Also, just leaving out support for this on those archs should be workable too. The hostname interface is documented in a lot of detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed -- we plan to offer similar documentation for the other mechanisms. Not all Linux distributions currently use systemd. The majority of the big and small distributions however has switched by now or is planning to switch in their next versions, or at least provides packages in the distribution. The one exception is Ubuntu. While I have hopes this will be resolved next year, there is no official statement from Ubuntu on this. Distributions not interested in systemd which however are looking into having some of its features could probably compile systemd but remove all but the mechanism daemons. Integration between gnome-session and systemd I expect to be very lose, and can probably easily be #ifdef'ed out for conservative distros or other OSes. The closest integration I expect in gdm. Ideally I'd like to rip out the current CK support completely and replace it entirely by the more low-level systemd specific code. However, that I can only do if the outcome of this discussion is clear. systemd itself has very minimal external dependencies. You need Linux, udev, D-Bus, and that's it. (there are a couple of additional optional deps however). The first version i'd like to see blessed is systemd 26. Comments? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ---End Message--- -- ubuntu-platform mailing list ubuntu-platf...@lists.canonical.com https://lists.canonical.com/mailman/listinfo/ubuntu-platform ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 13:00, Olav Vitters a écrit : It is called systemd, and it is NOT a dependency. What we depend on is a few simple dbus APIs. If an OS doesn't implement those APIs, certain functionality won't work. These APIs have been implemented in systemd, but they can (and are being) implemented elsewhere. What I've said above is nothing new btw (to me). It has been discussed openly, think on this mailing list. What I am suggesting now is that we clearly document this (depend on the API being implemented). Hi, Ok, so as a distributor of GNOME I think that what we (Ubuntu) would like to see: - some public list of what services GNOME rely on to be fully working - some public announce earlier in the cycle, or if possible one cycle in advance of what API will need to be provided for the next GNOME release to be fully working - some details (spec?) about the API used for those who want to implement compatible ones It's fine to be using new services but if GNOME wants distributors to provide a good GNOME experience system requirements should be announced in advances with a clear description of the protocol to give enough time to integrators to work on providing those services. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 15:47, Olav Vitters a écrit : FWIW and IMO, this is a packaging issue. If you want to provide GNOME 3.4, you'll need to ensure you have the right functionality in your OS/distribution. Well, GNOME should start by communicating what are the right functionality and doing it one cycle is advance would be nice, you can't assume that all your distributors track every git commit and will be able to accomodate new requirements added some weeks before feature freeze. Could you also point to a GNOME documentations telling what methods on this dbus service the system should implement for GNOME to be working correctly? The current way of doing things just seem far to be professional, GNOME can probably do much better on communicating their requirement and documenting them. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 15:49, Bastien Nocera a écrit : Most of them are listed in the page that Olav pointed to: https://live.gnome.org/PortabilityMatrix Not updating it for the latest changes is my mistake. This wiki page is something but it would be better if GNOME could: - do public announces a cycle in advance of what new system requirements will be added to let distributors adapt to those - document somewhere what interfaces exactly are required and since when The actual talk of using systemd's timedated and localed services was in May 2011: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00429.html And the bugzilla itself (for which you receive notification mails) opened since September. I think that's enough time to implement the functionality. Right, out of the fact that there were different opinions in the community on those topic and no consensus in that discussion, nor project statement that those new requirements had been approved and would be enforced. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 17:28, Matthias Clasen a écrit : How about: distributors should keep on top of what's happening with the things they are distributing ? Right, that's one possibility (and basically what it's happening nowadays), but it makes the distributors' job harder and so increases the likeness that GNOME users will get a suboptimal experience on their distribution. It's neither a win situation for GNOME since it's not showing as good as it should for those users nor for the distributors. Or maybe you just don't have time for that because you are busy working on your own platform ? Dunno for others but speaking for Ubuntu as a distribution we do keep with what is happening. This cycle we decided to stay on GNOME 3.2 so we are fine and we will have time to add the services required before landing 3.4 next cycle. Jeremy and some others are working to provide GNOME 3.4 in a ppa for the users who want it though, that will like create issues for them and for the users who will run the next version and will get a degraded experience. It's also going to be an issue for i.e Debian. They seemed to be looking at GNOME 3.4 for the next release (their freeze is a bit after 3.4) but they will not use systemd by default so they either have to figure what they can do with their limited resources, ship with non working features, or stay on 3.2. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le 20/01/2012 17:50, Bastien Nocera a écrit : In about 40 minutes, I created a binary RPM[1] that contains the 3 services we care about in GNOME from the systemd Fedora package. I believe you do something similar. Thanks, that works but is not really optiomal (i.e that could easily lead to a non well maintained,half broken systemd in Ubuntu because it has been packaged by people who care only about the services and not about the other features from systemd). But anyway from a distributor perspective this specific problem is orthogonal to the discussion: - the issue is not Debian,Ubuntu specific - the issue is not that distributors have work to do to integrate GNOME - nobody asked you to solve integration issues for downstreams What as a downstream we would like is early communication from the project on what platform requirements will be added so we have time to do our work and deliver a good GNOME experience to our GNOME users. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Le vendredi 20 mai 2011 à 11:11 -0400, Colin Walters a écrit : The best argument for having this as part of the OS is for the live CD scenario. You might as well type in your username each time if you have to pick language etc. too. Hi, The liveCD or the installer don't require any output, taking the Ubuntu example loco team distribute localized versions of the CD with the right locale by default, the liveCD autologin, you click on the installer, select your location and partitions then the installation start and you can deal with the customizations while the copy is happening. Having it done while the system is working is a time win over what you suggest Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le jeudi 19 mai 2011 à 12:00 +0200, Olav Vitters a écrit : So my conclusion is that it is better to suggest something else. Well using a ppa known to be a work in progress one != using Ubuntu, we didn't upgrade to GNOME3 because we didn't think we would do a solid work to integrate it on the schedule we had. The ppa is known to be experimental, from https://launchpad.net/~gnome3-team/+archive/gnome3you can read: This package contains packages from GNOME3 and their dependencies so they can be used in Ubuntu 11.04 (Natty). This PPA is EXPERIMENTAL and MAY BREAK YOUR SYSTEM. There is no downgrade process. It's fair that you don't recommend an unstable ppa but Ubuntu itself is shipping GNOME 2.32 and there is no reason it should create any issue users. Would you not recommend using Debian because GNOME3 is in experimental and using experimental might lead to some issues? Seems your statement there is just not a fair one. -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le jeudi 19 mai 2011 à 12:00 +0200, Olav Vitters a écrit : jhbuild on, I'd make clear that Ubuntu would mean a lot of difficulties. Some other people pointed that .la files can be problematic for jhbuild, note that Debian and Ubuntu have started cleaning those so this issue should start solving itself in the next cycles. -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 22:33 -0400, Matthias Clasen a écrit : I would take this a somewhat seriously, if it did not come from the distribution that embraced desktop-couch and 60+ M of erlang dependencies... Hi, Not sure such comments are constructive there. We do believe that desktopcouch is a nice technology and we decided to base some of the things we are doing on it. We didn't write it though and the erlang depends is coming with it. I fail to see why GNOME should judge distribution choices the way you are doing, we are still using GNOME as our default desktop and the fact that some of the choices we are making create some extra work for us shouldn't be a concern for GNOME. My email was just explaining what Ubuntu will be doing and why. So the upshot is that GNOME3 will be happening without contributions from your side I'm not sure to understand. I said we do plan to get there over 2 cycles, that we will get the platform GNOME3 and GTK3 ready this cycle but our default desktop will depends on it only next cycle (we will likely have GNOME3 in a ppa for this cycle for the users who want it). How is doing the work over two cycles and taking some time before switching not contributing? We will do what we can to help on GNOME3 and will be shipping it, we just believe our distribution doesn't have the capacity to make it happen by default for our users with our quality requirement in this cycle. while your team is busy building their own desktop experience with Ayatana and unity. Thats ok, lets just be honest about it and stop pretending. Not sure what you call your team there, the Canonical Dxteam is working on unity, my team which is the Canonical Desktop Team is working on the Ubuntu desktop, we are working on GNOME as we did since Ubuntu started and we do plan to work on landing GNOME3 in the desktop, it's just going to take us two cycles for the reason explaining before. The fact that other teams at Canonical work on some other projects doesn't mean we will stop using GNOME or contributing, we just have different products to respond to different customers and users needs. Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le samedi 12 juin 2010 à 16:55 +0100, Bastien Nocera a écrit : And you're telling me that your decision on keeping a GTK+ 2.x version is based on one distributor's dubious decision? GNOME 3.x will be based on GTK+ 3.x. Hey Bastien, We wouldn't be the first distribution to work on a GNOME version not being the most recent one for a cycle, that's a distribution choice and I'm not sure why it would be dubious? Take in account that some distributions out there are available and used and without gtk3 and will keep being used for a while (Debian, OpenSuse, RHEL, Ubuntu LTS, etc). It's reasonable for software writers to support having their new version to still build on those distribution to reach those users, why would you require everybody to drop gtk2 support? Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 10:53 +0200, Milan Bouchet-Valat a écrit : But is it very likely that Ubuntu CD will contain applications that still require GTK+2? Yes, I don't see for example firefox or openoffice switch to gtk3 in this cycle. this distribution is considering itself as pure downstream, and would rather patch all they can rather than spend this effort helping the move in GNOME itself. We do plan to help moving, we just don't think Ubuntu will be able to deal will all those transitions in one cycle Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le samedi 12 juin 2010 à 17:31 +0200, Xavier Claessens a écrit : Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3, and if we can't build Empathy with GTK2 then they'll just keep Empathy 2.30.x... tbh I think that's a bad decision from Ubuntu, but it would be really sad to not ship the latest empathy... Hi, It's not that easy. The Ubuntu team does think GNOME3 is moving in the right direction and that GTK3 will be great and wants to help to get there. In the same time we need to ship in octobre something solid our users rely on. We did discuss it a lot and the distribution might be quite popular our team is still quite small with limited manpower, the GTK3 transition will require quite some packaging work to build GTK3 versions of all those libraries and our one CD constraint will make challenging to ship 2 versions of the GTK stack. Realistically we aim at doing the packaging work and getting GTK3 in shape and in main this cycle but not in the default installation, we have planned the GNOME3 transition for Ubuntu over 2 cycles. But I guess if the whole GNOME 2.32 depends on GTK3 then they'll change their mind. No, we will just ship what we have now and keep working over 2 cycles on the GNOME3 update. One side note is that lot of users out there are on stable distributions versions which don't have GTK. Those distributions will not change for a while and those users will stay there. Now softwares writers have the choice to stop targeting those users and stop allowing GTK2 builds of their code or to allow building with either GTK2 and GTK3. I guess lot of upstreams out of GNOME will keep supporting GTK2 for some years which is a reasonable position, what matters for most upstream is to have their code used. I doubt that for example firefox or openoffice will drop support for GTK2 builds any time. I don't think because a software is part of GNOME means it should hard require GTK3 now and stop building on GTK2, it should rather be a maintainer decision on what they want for their software and users. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 11:38 +0100, Bastien Nocera a écrit : That's not a decision for the software writers to make when their code is in the GNOME release. Why would GNOME tell software writers that their code can't have build time options to use either gtk2 or gtk3? I don't see how that's a different problem from GNOME as a whole using a newer glib and pushing modules to use the new functionality. It's not really but GNOME never had rules saying that maintainers can't decide to add support for older version in their code if the newest glib is not available at build time. If OO.o or Firefox are blockers, where's the push to get those building against GTK+ 3.x? Not sure for who they are blocker, those are not part of GNOME and GNOME should not take decisions based on those. Distributors in the other side often have different requirements and take their decisions based on those. We will try to work on helping making those to build with GTK3, we just plan this work on several cycles for reason explained before. -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring 2.29 breakages
Le mercredi 17 mars 2010 à 23:51 +0100, Sebastien Bacher a écrit : The gnome-keyring maintainer has announced that he would not have much time for GNOME in the next months but the current 2.29 version seems to be broken in several ways which seem to be show stoppers for 2.30. Hi, Just to follow on the issue, Stef has replied to my email this weekend, he also fixed most of the bugs listed, thanks to him -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-keyring 2.29 breakages
Hi, The gnome-keyring maintainer has announced that he would not have much time for GNOME in the next months but the current 2.29 version seems to be broken in several ways which seem to be show stoppers for 2.30. The goal of this email is to raise the issue there and to see if there is some people who knows the gnome-keyring code who would feel like trying to help fixing some of the issues or reviewing changes. Those bugs seem good candidate to be on the 2.30 buglist: * g_k_store_password and g_k_find_password doesn't work properly when keyring is locked https://bugzilla.gnome.org/show_bug.cgi?id=611310 There is a small testcase showing that those callbacks don't work as they should when the keyring is locked. * Creates new default keyring each time program starts https://bugzilla.gnome.org/show_bug.cgi?id=611449 Calling gnome_keyring_create_sync() on an existent keyring used to return AlreadyExistsError and doesn't now, it breaks gajim for example * session keyring is stored to disk https://bugzilla.gnome.org/show_bug.cgi?id=612977 The bug could be flagged as a security issue, the session keyring is stored on disk where it's supposed to not be? The effects of those breakages seem quite noticable in some cases: * Empathy (or mission-control) seems unable to unlock the keyring with libgnome-keyring 2.29, which means if an user use autologin and start empathy creating or connecting to accounts fails. The issue seems similar to the bug #611310. Empathy works correctly if the keyring is unlocked by entering a password in gdm or using an another software in the session before running empathy. * Several users reported issues about gvfs-sftp or gvfs-smb eating cpu when trying to use a stored password or asking for the password when changing sftp directories rather than using the store one * Bugzilla also has some patches fixing build issues which would be nice to get reviewed and some other bugs worth investigating Thanks, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
Le lundi 22 septembre 2008 à 18:47 +0800, Davyd Madeley a écrit : If you've called the function in GTK+ directly, you never specify a page_size (it doesn't make sense). If you've set a non-zero page_size, it's really your own fault. Hi, how do you expect the people using gtk to guess that? the gtk_spin_button has no note about the adjustement and the example are buggy and use a non null value Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GTK adjustement changes create incompatible behaviour between versions?
Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. I'm copying the desktop-devel-list too because GNOME 2.24 is due next week and it's likely that several GNOME desktop applications have not been updated for those changes Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring has SSH, X.509 certificate and key support
Le lundi 03 décembre 2007 à 16:48 +, Stef Walter a écrit : Sebastien Bacher wrote: While looking at the new version I noticed that the library is called gnome-keyring-pkcs11.so rather than libgnome-keyring-pkcs11.so, any reason to not use a standard library naming? Well it's more of a 'module', and not used by the linker. it's dlopen'ed directly by processes, and specified in configuration files. I figured that it would be simpler to leave off the 'lib' in this case, since its not necessary. But if it does break something, then it can certainly be changed. Hi, You could maybe use the /usr/lib/gnome-keyring directory to store the binary as gnome-keyring-pkcs11.so in this case rather than using a soname, installing a static version, etc? Sebastien Bacher ___ 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?))
Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit : Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? I don't think it is fair to state this. A lot of people certainly care about hacking on GNOME and don't know git (and don't care about it). I think Vincent is right there, looks like some people are using git and trying to make it look like that's the case for everybody else in the GNOME world which is not correct Cheers, Sebastien Bacher ___ 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?
Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : Of course no project using git maintains ChangeLog. Why? You could update the ChangeLog when commiting changes on git Cheers, Sebastien Bacher ___ 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?
Le lundi 17 septembre 2007 à 10:49 +0100, Emmanuele Bassi a écrit : generating a ChangeLog from the git log is something that should be done at release time, when you are preparing the tarball, as the users of the package have no access to the git repository history. looks like we don't have the same definition of maintaining a ChangeLog, if you generate one from git when rolling a tarball that's good enough for people using the tarballs Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: shared-mime-info minimum version update
Le jeudi 21 juin 2007 à 11:05 -0400, Matthias Clasen a écrit : On 6/21/07, Luca Ferretti [EMAIL PROTECTED] wrote: The shared-mime-info product itself is not translatable[1] 'cause you are not using launchpad to manage it. Thats nonsense. Why? It's saying that you can't translate shared-mime-info there because upstream is not using launchpad, which is true. Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Control Centre
On lun, 2007-02-05 at 19:19 +, Alex Jones wrote: Down with control centre. I want my menus back. Changing settings just isn't the quick in-and-out-in-5-seconds-flat job it used to be. Hi, That has already been discussed, the plan for GNOME 2.18 is to use the shell and to have an easy way (likely from the menu editor) to get the menus for people who prefer them Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
Le jeudi 19 octobre 2006 à 13:36 +0100, Jamie McCracken a écrit : We will be pushing for this in ubuntu edgy+1 Will we? Where has this been decided? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
Le jeudi 19 octobre 2006 à 16:21 +0200, Martin Soto a écrit : Hello Sebastien, On Thu, 2006-10-19 at 16:01 +0200, Sebastien Bacher wrote: Le jeudi 19 octobre 2006 à 13:36 +0100, Jamie McCracken a écrit : We will be pushing for this in ubuntu edgy+1 Will we? Where has this been decided? I guess it is clear from the context (which you aren't including in your message) that with we, he is refering to the group of Tracker developers, who are planning to lobby for inclusion of Tracker in Edgy +1. I don't think that being that picky helps the discussion at alll. (No need to reply on my email, I'm subscribed on the list) I'm not being that picky, just pointing that nothing has been decided about tracker for edgy+1 yet because the previous mail could be confusing Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
Le jeudi 19 octobre 2006 à 10:13 -0400, Hubert Figuiere a écrit : If they need somebody to upload it to universe, I'll happily submit it :-) Having tracker packaged to universe would be great. I would be happy to sponsor the package or give a hand to whoever package it too ;) My previous mail was just to point that there is no decision on the Ubuntu side about using tracker on the default desktop next cycle Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Le lundi 24 juillet 2006 à 23:43 -0400, Luis Villa a écrit : Ubuntu does better than anyone has done it since... well, a long time, at any rate. And by Ubuntu I mostly mean *you*, which makes me worry about burnout, sustainability, etc., but that's a different discussion, probably. Right, different topic, I just want to point that Daniel Holbach is spending a good deal of efforts on forwarding bugs upstream too and we are trying the ubuntu-qa team to work on that too No, of course not. But most distros don't do either the filtering *or* the upstreaming, and given the choice between unfiltered traces or none at all, we must choose unfiltered. The issue is to know if there is enough people working on triaging bugs upstream to keep up with all those bugs that would be sent... takes place at the gnome level, the duplication can be reduced. Right, people triaging upstream are always welcome and that would be nice to have distributions contributing actively to that! Again, I'm sorry I offended- the different distros have different success levels here, and obviously over the past 12-24 months Ubuntu has been pretty much a model. I think there is still a lot to be done, though, especially in automation and filtering, for all parties. No offense, I was just trying to point that dumping load of bugs directly upstream might not be a better solution than what we have at the moment because of the workload it would put on the limit bugsquad man power. Anyway as you said there lot to be done so let's everybody work in that direction ;) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On ven, 2006-07-21 at 11:28 -0600, Brent Smith wrote: NoDisplay=true in the .desktop file as I don't believe the gmenu API returns these applications. Since gnome-menus 2.13.5 there is a GMENU_TREE_FLAGS_INCLUDE_NODISPLAY flag allowing to do that Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bug buddy maintainer? (Was Re: bug-buddy support)
On ven, 2006-07-21 at 11:28 -0600, Brent Smith wrote: Unfortunately, this causes problems for programs which are not included in the menus (like evince and yelp) I've attached a patch to bug #347422 that fixes that issue Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 03:28 -0400, Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) I though we were doing a pretty good job at forwarding Ubuntu bugs upstream, but apparently it looks like you don't appreciate the efforts, makes me wonder if we should bother keeping doing that then So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. There you assume than distros don't send back useful informations upstream and than distros are doing no QA. What we are trying to do with bugs about the Ubuntu desktop is to get something useful before forwarding them upstream. I would have no issue to just dump hundred of useless bugs and non-debug backtraces upstream and stop trying getting details for them if you think that would be better complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the Luis, have you read the Ubuntu spec pointed by Ben? A part of it is about getting better backtraces, Martin Pitt already did some good work on it and it's likely we will get automatic debug backtraces when something crash for Ubuntu edgy Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 09:52 +0100, Bastien Nocera wrote: I was in discussions with another maintainer of core GNOME modules (that shall remained anonymous), and we were not very impressed at the way Ubuntu forwarded bugs. Right, there is probably nothing to be impressed about but we try to get useful details (debug backtrace by example) and to forward as many upstream issues as possible, no doubt we could do better though. Anything special you would like to get changed from the bugs we forward? (saying that you are not very impressed doesn't give anything special to work on to make that better) Bugs caused by Ubuntu specific patches should not be able to make their way to the GNOME bugzilla I don't think Ubuntu maintainers are forwarding a lot of bugs due to Ubuntu patches upstream but maybe your experience is different? Users are a different issue. We try to push people to report bugs to Ubuntu when they are not sure of what they are doing so we can filter distribution specific ones before sending them upstream but we can't stop people using bug-buddy or bugzilla if they want and patches that aren't brand or slight preferences fixing should have an upstream bugzilla. I have seen some patches showing up in b.g.o after having been in Ubuntu for months. Agreed, that is an issue for pretty much every distribution around. I looked at some fedora, mandriva and suse packages for useful patches we could use for Ubuntu before dapper, and all of them have GNOME patches that would be welcome upstream and have not been forwarded, so nothing specific to Ubuntu on that, but right we should try to do better on that Gathering backtraces should be done in launchpad before a bug is opened upstream, and it's not the case sometimes. That's one of the things we are working one and what Luis was complaining about So it's not perfect, but I'm sure you'll get there. Right, it's far for being perfect at the moment but I think it's still better than sending everything directly upstream by bud-buddy (which was the point of my first mail). Note that the purpose of the mail was not to say Ubuntu does a particularly good job at it, but to point that the job done by distributions might not be perfect but is still something useful and there is no reason flooding directly upstream with distributions bug would be better for GNOME Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgswitchit + libkbdraw = ... ?
On dim, 2006-07-09 at 23:17 +0100, Sergey Udaltsov wrote: I see the Ben's point but I have strong concern that solutions like this could easily make GNOME any distrobuilder's nightmare. So here is the question: would gnome build process stand 2(!!!) new TINY(!) libraries - or is there better way to handle this? Comments are welcome, hi, From a distro point of view I don't think those libraries are an issue, they only need to be packaged which is not that much work and usually distributions prefer a proper library to code copied to several places since it's easier to fix the library than to patch several applications having a copy of it Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center renaming to gnome-control-center
Le lundi 29 mai 2006 à 08:11 -0600, Elijah Newren a écrit : Awesome, assuming no one has any reason against it, thanks for making things more sane. Would it also be okay if I changed the bugzilla module name for you (from control-center to gnome-control-center) so that all three match? Would be nice but I thought than changing the bugzilla componant was an issue for bug-buddy by example (that was bkor said on IRC when system-monitor was renamed to gnome-system-monitor) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Slowdown when running gconftool-2 --makefile-(un)install-rule
Le dimanche 05 mars 2006 à 22:30 +0100, Jan de Groot a écrit : In archlinux, we used gconftool-2 --makefile-uninstall-rule on pre_upgrade of all our packages with schema files, while using --makefile-install-rule on post_upgrade or post_install on all schema files installed by the package. While such a process takes 10-15 seconds max per package to install with gconf 2.12, it takes over a minute or two to install packages with quite some GConf schemas on 2.13. I guess the merged database things cause this big slowdown, as it generates a merge on every run of gconftool-2. What options do we have to speed this process up a bit? Hi, The Debian maintainer of gconf has sent a patch about that: http://bugzilla.gnome.org/show_bug.cgi?id=53 Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session api break
Le mardi 28 février 2006 à 16:55 +0100, Rodrigo Moya a écrit : again, since only 1 module in GNOME CVS uses it, why would we need to support the old directory? I can add that code if you want, but I see no point in doing it, since no applications use that directory (at least in GNOME CVS). Hi, I think we should do the change and look for both place. That way it'll work for everybody, doesn't break current implementations for distribution using it (like FC5) and has the bonus to allow the system administrator to put some custom .desktop to /etc where the packages use /usr Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
some breakages due to icons move from hicolor to gnome
Hi, During that cycle a lot of icons from gnome-icon-theme have been moved from hicolor to gnome, that has for effect to cause different sort of breakages, by example: - it breaks GNOME applications for people using them with a non-using-GNOME theme (some time ago an evolution user using xfce was complaining that after updating most of the icons are broken for him. a kubuntu maintainer has just been reporting a GNOME application crashing on KDE with crystal icon theme because gnome-settings-default-applications has been moved to gnome theme) - when login to GNOME, if gnome-panel (with some launchers using gnome icons like web-browser) starts before having gnome-settings-daemon applying the icon theme you get error dialog about the icons beeing not found I've opened http://bugzilla.gnome.org/show_bug.cgi?id=330061 about that. The maintainer argue that installing icons to hicolor is wrong. So what should applications do? Stop using icons from gnome-icon-theme? Accept to be broken for people running GNOME applications from KDE by example? That seems to be a compability breakage, quite a lot of applications are actually using icons which used to be shipped to hicolor and will have issues now. GTK has a xsetting since 2.8.10 (discussed on http://bugzilla.gnome.org/show_bug.cgi?id=325546) to set an another fallback before hicolor which can act as a workaround, but since no other desktop set it at the moment it doesn't change the frustation for users to have things broken on upgrade Any opinion on the topic? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: difficult string in gnome-panel
Le samedi 07 janvier 2006 à 11:56 +0100, Reinout van Schouwen a écrit : Hi, I found this string in the latest gnome-panel: #: ../gnome-panel/panel-menu-bar.c:86 msgid Open and search local, remote and recently-used documents and folders I don't know if the meaning of this is obvious for the average English reader, but I have to make two or three sentences out of it to translate it properly, because there is so much information conveyed in just a few words. Can't this tooltip be simplified a little bit? hi, Maybe bugzilla is a better place than the desktop list to raise some issue about a gnome-panel string? :) -- Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libnotify and notification-daemon for GNOME 2.14
Le mardi 03 janvier 2006 à 17:19 +0100, Rodrigo Moya a écrit : anybody has changed any of the apps that use the old version to use the new one? Ubuntu has patches for evolution/gnome-applets which are attached to bugzilla.gnome but not applied yet Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf merged tree with split translations
Le mardi 03 janvier 2006 à 17:32 +, Mark McLoughlin a écrit : Hi, I've switched this on by default now for the defaults database now. Please keep an eye out for any weird issues that might have been caused by this. hi, Do you have any plan to roll a new tarball of gconf with that? It would be nice for distros by example :) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time for the annual bugzilla statistics
Le dimanche 01 janvier 2006 à 21:26 -0700, Elijah Newren a écrit : The following people closed more than 750 bugs in 2005: 2329Sebastien Bacher 1183Matthias Clasen 1093Olav Vitters 1092Andre Klapper 939 Kjartan Maraas Nice work on that, thanks for the summary. I have one question though, how come that you are not on that list? :) According to weekly-bug-summary.cgi you should be on the first place for 2005 and you deserve it with all the work you did! Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: do we really need xrdb?
Le lundi 17 octobre 2005 à 09:32 -0600, Elijah Newren a écrit : we could achieve the same benefit by just calling xrdb with the -nocpp We tried that before Ubuntu 5.10 and had some issues: https://bugzilla.ubuntu.com/show_bug.cgi?id=14268 Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The GConf key /desktop/gnome/interface/file_chooser_backend
Le samedi 30 juillet 2005 à 18:43 +0100, Darren Adams a écrit : Hello there, Can anybody tell me what application / library / component makes use of the GConf key /desktop/gnome/interface/file_chooser_backend? It's just that I'm using Ubuntu Breezy and I'm trying to track down something that's making the file chooser crash when it seems to be using the gnome-vfs file chooser back end. Hi, You probably speak about http://bugzilla.gnome.org/show_bug.cgi?id=310270 ? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggcups (and libgnomecups) for 2.12
Le mercredi 20 juillet 2005 à 14:56 +0200, Murray Cumming a écrit : So this is what gives me the printer icon in the notification tray in fedora? Ubuntu has something similar? That's gnome-cups-icon, right? What's the story/comparison there? Right, Ubuntu uses gnome-cups-manager which has gnome-cups-icon to do this. gnome-cups-manager also has an UI which make possible to configure whatever printer you want, eggcups has not such feature (it autodetects USB printers but if you have a smb or a lp printer you are screwed). Which means that some people will probably install both (Ubuntu will not drop gnome-cups-manager by example) and get duplicated features ... Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PATCH for using gnome-screensaver if available in gnome-control-center
Le mercredi 20 juillet 2005 à 15:23 +0200, Rodrigo Moya a écrit : Hi This patch makes gnome-control-center use gnome-screensaver when available. Ok to commit? Hi, There is already a patch on bugzilla about this for some time: http://bugzilla.gnome.org/show_bug.cgi?id=302347 Maybe you can attach your patch here too and use the bug to discuss it? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggcups (and libgnomecups) for 2.12
Le mercredi 20 juillet 2005 à 09:36 -0600, Elijah Newren a écrit : Colin requested that only the job-notification aspect of eggcups be considered for inclusion in 2.12. (http://mail.gnome.org/archives/desktop-devel-list/2005-July/msg00252.html). Right, I'm just pointing that it will give a duplicate if gnome-cups-manager is not changed (but changing it should not be an issue). Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggcups (and libgnomecups) for 2.12
Le mercredi 20 juillet 2005 à 11:28 -0400, Colin Walters a écrit : disable the tray icon. Wouldn't that suffice for distributors wanting to ship both? Yeah, as far as the feature is not duplicate that's fine. Using gnome-cups-manager to install printers with eggcups for the notification seems to be best option :) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: /desktop/gnome/applications/window_manager
Le mardi 19 juillet 2005 à 13:45 +0100, Mark McLoughlin a écrit : On Mon, 2005-07-18 at 10:20 +0100, Mark McLoughlin wrote: 1) Add deprecation notices to the docs for all of those keys 2) Remove the setting of default in gnome-wm 3) Remove the wm-properties code in gnome-control-center/capplets and libwindow-settings (wm-exec.c, wm-list.c and wm-properties.h) to avoid any further confusion. Done on HEAD now. Thanks! Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggcups (and libgnomecups) for 2.12
Le mercredi 13 juillet 2005 à 19:56 -0400, Colin Walters a écrit : Opinions? Hi, It seems pretty minimalistic, there is no UI to configure a non-detectable printer by example (lp, smb, ...). Wouldn't gnome-cups-manager be better for users? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: switching to g-c-c shell? [Was: Re: Control center and capplet merging]
Le jeudi 07 juillet 2005 à 10:57 +0100, Bastien Nocera a écrit : On Thu, 2005-07-07 at 11:43 +1000, Jeff Waugh wrote: snip (As hideous as the Sound crapplet is), Martin has put a choose your output device dropdown in the Sound crapplet in breezy, and some hotplugging stuff to go with it. If we didn't have so much trouble with middle layers of the audio stack (read: mixing), this is what the user-interesting functionality would be. This needs some... integrationary massage before going upstream, but it's a good step. Does Martin read utopia-list? He does. About the sound selector mentionned by Martin has put that on bugzilla and is waiting for comments/to discussion about this: http://bugzilla.gnome.org/show_bug.cgi?id=305907 Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCE: Deskbar Applet 0.3 (keybindings)
Le jeudi 30 juin 2005 à 19:02 -0400, Luis Villa a écrit : Hasn't Sebastien Bacher taken Jonathan's place in the g-c-c maintainers? News to me. :) Seb? hum ... I do some work on it and roll the tarballs ... but there is some room for several maintainers on it, let's say I'm one of them :) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
Le vendredi 10 juin 2005 à 13:10 -0400, Luis Villa a écrit : Each of the major distributors could (should?) package 2.7.0 I've put .deb packages (i386) of the current pango/gtk CVS for Ubuntu here: deb http://people.ubuntu.com/~seb128/gtk ./ Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-control-center branched for gnome-2-10
Hi, gnome-control-center has branched for gnome-2-10. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.10 Showstoppers - Update
Le jeudi 17 février 2005 à 09:28 -0500, Vincent Noel a écrit : #166987 (shell) : NEW ! CC Graphical shell window freeze when resized In some undetermined circumstances, the shell window freezes when resized. As the shell window can only be accessed with --use-shell, this bug is unlikely to get triggered by users, thus it is unclear why it is considered a showstopper... Probably no good reason, I've set it because the icons alignement is broken (which is ugly) and the hang issue is easy to get for the submitter. Apparently that's not reproducible for everybody, I've changed the Milestone for the moment. #146075 : Crash while adding images to desktop To reproduce : Activate translucent panel, open the background capplet and quickly switch the background image twice. An X error is produced in panel-background-monitor, that lead to an applet crash and eventually a panel crash. Sneaky bug with plenty of duplicates. Unclear how to fix it. Update : more duplicates, but all from 2.8. The bug might be fixed, unless a 2.9 dup shows up. Really easy to get with the current devel releases here, Vincent Untz known about the issue. #128317 has a patch that fixes the issue here. #158718 : crash during apt-get upgrade Comment #2 suggests gnome-volume-manager crashed during a restart. 3 duplicates. Did not seem to get a lot of attention. Update : may be Ubuntu-specific. Right, I've added a comment on the bug. According to the Debian's maintainer gnome-volume-manager doesn't handle dbus restarts at all. There is a patch in bugzilla for that for some time: http://bugzilla.gnome.org/show_bug.cgi?id=153673 Cheer, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
