Re: Killing bug-buddy?
On Fri, 2011-08-26 at 09:46 +0200, Olav Vitters wrote: I guess you want to kill bug-buddy for regular users only, as you was talking about bugzilla connection, because ABRT is unusable for developers, as it silently ignores crashes in applications which are not packaged, furthermore, if you enable to catch crashes of unpackaged Do you know how difficult would it to change that behaviour in ABRT? Make it support jhbuild? Hi, enabling abrt to catch unpackaged applications is easy, just edit /etc/abrt/abrt.conf and change ProcessUnpackaged = no to ProcessUnpackaged = yes I do not know whether it is doable with other than root user, though, but I feel that this is not an option for regular jhbuild users. applications, then it is not able to get the backtrace right. That's a reason why I resurrected bug-buddy on my machine, also for gtk3 applications, thus I know why my application is crashing, and when. Doesn't it just run gdb? I'd still think it is best to fix ABRT than to have multiple tools to report crashers. I just gave this a try, just in case, with abrt 2.0.3, and it gathers bactraces for unpackaged files correctly now, thus they fixed it since I tried the last time, which, I confess, is some time ago. I suspect it had been fixed together with an access to .xsession-errors file, to which abrt daemon didn't have access in previous versions too. Anyway, I'm not an ABRT developer, I only face its reports and try to get something useful from them. If you've any questions, then it's better to ask ABRT developers, as they know all about it. One note I forgot to mention in the previous mail: From my point of view, the all information brought in by ABRT is usually unnecessary, as for me is backtrace enough, and when I would like to ask for more info then I'll ask a reporter. Also, ABRT tends to attach backtraces instead of pasting them in a comment, which results in unsearchable bugzilla for duplicates. That all might be changeable, maybe it already is or with a cooperation with them. As an example see this ABRT report: https://bugzilla.redhat.com/show_bug.cgi?id=733505 there is, from my point of view, tons of crap till you get to the only valuable information, which is a backtrace (unfortunately attached), and console output (the .xsession-errors). These are two things I usually look at and silently ignore the rest. ABRT has some functionality to disable unneeded output already, as is stated in: https://fedorahosted.org/abrt/ticket/226 How it is with forcing backtraces as comments, not as attachments, I do not know. It's subject to check out, and as you said, some developing is still required, then it'll be great once it's done. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On 31/08/11 22:26, Federico Mena Quintero wrote: On Tue, 2011-08-30 at 15:24 -0400, Shaun McCance wrote: Hey Federico, I noticed that we have Contacts, Documents, and Sushi in the apps moduleset. gnome-documents worries me because of its dependency on Tracker. As far as I can tell, g-d is linked from https://live.gnome.org/ThreePointOne/Features/FindingAndReminding - to https://live.gnome.org/Design/Apps/Documents - which are just factual or planning pages, not discussion pages. (FindingAndReminding is even marked obsolete! - what about the sublinks to Document-Centric Gnome?) With the inclusion of gnome-documents, we are validating Tracker as *the* metadata store for Gnome. Tracker has many implications, and I would like to see a good discussion of whether it is the right thing for Gnome. Some starting points: - How is an existing $HOME handled? In terms of what? If you mean what data is indexed I can say that we index all files in $HOME (no sub-directories) and then we independently index all XDG directories thereafter recursively (e.g. $HOME/Documents or $HOME/Music, etc as it commonly is in distros). - What kind of maintenance needs to be done on the database? Usually the maintenance done on the Tracker databases is done in the way of ontology updates. The ontology describes the schema which we spit out and use in SQLite. So any maintenance done on the database is usually in the form of: user asks for features x, y an z and we update our ontology (which updates the database). We have gone to great lengths to ensure redundancy for user data and also to support various schema updates (e.g. changing a column from one type to another or adding new tables/properties). Most of this is handled automatically. There is more information on the wiki: https://live.gnome.org/Tracker/Documentation/SupportedOntologyChanges - Are we storing full-text indexes in the same database? Yes. Stored as binary blobs. It used to be separate but SQLite is slower and doesn't guarantee ACID¹ with multiple DBs and WAL². It also depends on how tracker is compiled. There is an option for it to be disabled. It's enabled by default. ¹ http://en.wikipedia.org/wiki/ACID ² http://www.sqlite.org/draft/wal.html - Are we storing non-metadata (e.g. contacts) in the database? By we, if you mean the GNOME community then no, however Nokia have extensively used it for the last year+. The ontology there is well tested at least but I don't think anyone is using that actively in the desktop yet. I could be wrong. - How do we handle metadata movement when files move around? In the database one field changes, the filename (IIRC), the rest is relational and no new extraction or heavy database changes are required. - Is Tracker well-maintained now that Nokia is switching to something else? (I'm not sure if this is the right question, but something along those lines.) Good question. I think upstream will always get some attention, how much is hard to say. Nokia is really providing a lot of bug fixing and testing which is why Tracker is quite a solid project right now. I and others on the team like Juergbi, Adrien, Aleksander, etc have been committing patches in GNOME bugzilla in their spare time also. There are also quite some people submitting patches upstream - which we don't get from Nokia. Intel are also using Tracker in MeeGo so it's in use in more than one place and I believe they're patching it too (internally and upstream). -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On Wed, 2011-08-31 at 16:26 -0500, Federico Mena Quintero wrote: (FindingAndReminding is even marked obsolete! For clarification: This just refers to its status for 3.2, it does not necessarily refer to future GNOME releases. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
Hi again! Anyway we're late, and I'll ask you for two more days of patience, so that we have the time to meet and give you a proper answer on the practical questions you have; and we will make sure this gets improved in the future. So we had our release team meeting yesterday evening, Shaun wrote: I noticed that we have Contacts, Documents, and Sushi in the apps moduleset. If shipped, all of these are just core parts of the desktop experience, so I want to document them in the desktop help. But I'm wary of doing that for modules in apps. Documents will just be a preview release, it shows the direction, nothing more, nothing less, I don't think it's worth including it in the desktop help for 3.2. On the other hand the features provided by Contacts and Sushi certainly have their place in the help. Apart of those, other new help topics could be colour management, onscreen keyboard, and support for tablets. I hope this answers your question, we are really sorry to provide you this info so late in the cycle, we are still commited to keep going on with the feature focused process, but we will improve the schedule, and the reporting from the release team. And really, don't hesitate to pester us whenever you feel we are acting in a black box. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Am 01.09.2011 11:34, schrieb Frederic Peters: Hello all, This is 3.1.90, and it's out! It's the first beta of what will be GNOME 3.2, enjoy it while it's time, the next beta (3.1.91) will arrive next week. I saw this in the release notes of gnome-control-center: Power: - Remove power and suspend buttons config (Bastien Nocera) (#652183) (#657068) I am sad. I know that the GNOME design team has its reasons to promote Suspend; it is great from a usability perspective, and I also suspend often and like it. However, I feel that the rigor with which this is pushed upon the complete user base of GNOME (minus those are knowledgeable enough to change a hidden dconf setting) is not right. While suspending is convenient, many people do want to save power when they don't use their desktop or laptop over night, or simply because they only use it one or two hours a day anyway. I don't see this as a minor use case; its a general consideration of many, enviromentally aware people, especially in European countries such as Germany where the Green party is going strong and we are already warned about the environmental impact of standby devices in elementary school. Regardless of their technical knowledge, such people will be put off by not being able to properly shut off, or having to jump trough hoops to do so. They will think that GNOME doesn't care about the environment. I don't want our wonderful community to make that impression. I don't want to start yet another flame war with this message (please, let's be sensible and respectful when discussing this). Neither do I want to denounce the design team; in fact, I greatly respect the design team for the many things it has done to make GNOME 3 the awesome piece of software that it is today, and that it will be tomorrow. I also don't want to throw everybody from the design team in the same pot: there are GNOME designers that are sympathetic towards some kind of compromise, as the discussion around bug #652183 [1] reveals. However, I feel that the current situation is not right, and that *something* has to be done to reach a solution that combines a high degree of usability with easily accessible ways to act environmentally responsible. Best regards, Denis Washington [1] https://bugzilla.gnome.org/show_bug.cgi?id=652183 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Hey Denis! On Thu, Sep 1, 2011 at 1:18 PM, Denis Washington den...@online.de wrote: Am 01.09.2011 11:34, schrieb Frederic Peters: Hello all, This is 3.1.90, and it's out! It's the first beta of what will be GNOME 3.2, enjoy it while it's time, the next beta (3.1.91) will arrive next week. I saw this in the release notes of gnome-control-center: Power: - Remove power and suspend buttons config (Bastien Nocera) (#652183) (#657068) I am sad. Oh dear, don't be sad! The intent behind those changes is to ensure consistency and predictability. If we know what the behaviour of the hard buttons is going to be, we can produce better designs elsewhere and it is easier to provide users with advice and guidance. Also, we really want to be able to specify separate long and short button press actions for the hard power button (like on a mobile phone). It is hard to accommodate that kind of behaviour within a set of preferences that are easy to understand. I know that the GNOME design team has its reasons to promote Suspend; it is great from a usability perspective, and I also suspend often and like it. However, I feel that the rigor with which this is pushed upon the complete user base of GNOME (minus those are knowledgeable enough to change a hidden dconf setting) is not right. While suspending is convenient, many people do want to save power when they don't use their desktop or laptop over night, or simply because they only use it one or two hours a day anyway. I don't see this as a minor use case; its a general consideration of many, enviromentally aware people, especially in European countries such as Germany where the Green party is going strong and we are already warned about the environmental impact of standby devices in elementary school. Regardless of their technical knowledge, such people will be put off by not being able to properly shut off, or having to jump trough hoops to do so. They will think that GNOME doesn't care about the environment. I don't want our wonderful community to make that impression. I don't want to start yet another flame war with this message (please, let's be sensible and respectful when discussing this). Neither do I want to denounce the design team; in fact, I greatly respect the design team for the many things it has done to make GNOME 3 the awesome piece of software that it is today, and that it will be tomorrow. I also don't want to throw everybody from the design team in the same pot: there are GNOME designers that are sympathetic towards some kind of compromise, as the discussion around bug #652183 [1] reveals. However, I feel that the current situation is not right, and that *something* has to be done to reach a solution that combines a high degree of usability with easily accessible ways to act environmentally responsible. I honestly think that the behaviour of those buttons is a separate issue from whether they should be configurable or not. Thanks for the kind words. :) Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On Thu, 2011-09-01 at 11:25 +0200, Frederic Peters wrote: Shaun wrote: I noticed that we have Contacts, Documents, and Sushi in the apps moduleset. If shipped, all of these are just core parts of the desktop experience, so I want to document them in the desktop help. But I'm wary of doing that for modules in apps. Documents will just be a preview release, it shows the direction, nothing more, nothing less, I don't think it's worth including it in the desktop help for 3.2. On the other hand the features provided by Contacts and Sushi certainly have their place in the help. Thanks. We'll update the help accordingly. Apart of those, other new help topics could be colour management, We already have 21 topics on color management, thanks to Richard. onscreen keyboard, and support for tablets. Is there more information on what all support for tablets means? I suppose the onscreen keyboard is relevant for tablet users, as well as being an accessibility feature. What else? I hope this answers your question, we are really sorry to provide you this info so late in the cycle, we are still commited to keep going on with the feature focused process, but we will improve the schedule, and the reporting from the release team. And really, don't hesitate to pester us whenever you feel we are acting in a black box. Thanks Fred. Sorry if my email came off harsh. I realize we've shaken things up a bit, and we're still ironing out the kinks. 3.0 was the first time in a long time that our desktop help was current and correct. I'm proud of the docs team for that, and I want to make sure we don't fall back. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
Hi Federico, On Wed, 2011-08-31 at 16:26 -0500, Federico Mena Quintero wrote: With the inclusion of gnome-documents, we are validating Tracker as *the* metadata store for Gnome. Kind of yeah; Tracker is pretty much an unique technology in the platform though and I don't see many alternatives. Tracker has many implications, and I would like to see a good discussion of whether it is the right thing for Gnome. Can we please think about it as does Tracker allow me to implement an innovative application that wasn't possible before rather than is Tracker useful for Gnome? Something like Documents would be a lot harder to implement without Tracker's help. Anyway most of the questions have been answered already by Martyn and Jasper, so I only have a couple of points. - Are we storing full-text indexes in the same database? Right now Documents doesn't use the full text search capabilities of Tracker. - Are we storing non-metadata (e.g. contacts) in the database? Documents makes use of the contact ontologies to display author information for indexed document files, and the GDocs miner stores there the same author information as provided by the server. These are usually triples in the format mailto:foo@bar a nco:Contact mailto:foo@bar nco:fullname Foo Bar urn:my-resource nco:author mailto:foo@bar The Contacts application doesn't store or read anything in Tracker as far as I know, but goes through libfolks. - Is Tracker well-maintained now that Nokia is switching to something else? (I'm not sure if this is the right question, but something along those lines.) I have to say the Tracker team has been very responsive to my questions, and bugs got quickly fixed when I reported them. Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On Thu, 2011-09-01 at 09:22 -0400, Shaun McCance wrote: On Thu, 2011-09-01 at 11:25 +0200, Frederic Peters wrote: Shaun wrote: I noticed that we have Contacts, Documents, and Sushi in the apps moduleset. If shipped, all of these are just core parts of the desktop experience, so I want to document them in the desktop help. But I'm wary of doing that for modules in apps. Documents will just be a preview release, it shows the direction, nothing more, nothing less, I don't think it's worth including it in the desktop help for 3.2. On the other hand the features provided by Contacts and Sushi certainly have their place in the help. Thanks. We'll update the help accordingly. Apart of those, other new help topics could be colour management, We already have 21 topics on color management, thanks to Richard. onscreen keyboard, and support for tablets. Is there more information on what all support for tablets means? I suppose the onscreen keyboard is relevant for tablet users, as well as being an accessibility feature. What else? Wacom graphics tablet. Which Peter Hutterer wrote, is currently working on fixing with Jimmac's help. As for the OSK, I don't think we'll have time to integrate this properly for GNOME 3.2, unless Dan does magic soon. We already have a UI for setting up the OSK, but things get very complicated if you want the old caribou in fallback and the OSK when running in the shell. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Am 01.09.2011 15:22, schrieb Allan Day: Hey Denis! On Thu, Sep 1, 2011 at 1:18 PM, Denis Washingtonden...@online.de wrote: Am 01.09.2011 11:34, schrieb Frederic Peters: Hello all, This is 3.1.90, and it's out! It's the first beta of what will be GNOME 3.2, enjoy it while it's time, the next beta (3.1.91) will arrive next week. I saw this in the release notes of gnome-control-center: Power: - Remove power and suspend buttons config (Bastien Nocera) (#652183) (#657068) I am sad. Oh dear, don't be sad! The intent behind those changes is to ensure consistency and predictability. If we know what the behaviour of the hard buttons is going to be, we can produce better designs elsewhere and it is easier to provide users with advice and guidance. Also, we really want to be able to specify separate long and short button press actions for the hard power button (like on a mobile phone). It is hard to accommodate that kind of behaviour within a set of preferences that are easy to understand. Sounds interesting, though there is still the discoverability issue: you would have to know that a long button press powers off, and that pressing the power button gives you a shutdown method not accessible from the shell. (In fact, there are still a surprising number of people who still think that you must never ever touch the power button or risk your computer's health otherwise.) Having said that, I'd like to make clear that the option itself is not what I am sad about. In fact, I would even be happy about the removal if the default behavior were sane and allowed me, and everyone who wants to do so, to easily discover a choose an energy-preserving full shutdown method. But currently, this is not the case, and this is what worries me. I know that the GNOME design team has its reasons to promote Suspend; it is great from a usability perspective, and I also suspend often and like it. However, I feel that the rigor with which this is pushed upon the complete user base of GNOME (minus those are knowledgeable enough to change a hidden dconf setting) is not right. While suspending is convenient, many people do want to save power when they don't use their desktop or laptop over night, or simply because they only use it one or two hours a day anyway. I don't see this as a minor use case; its a general consideration of many, enviromentally aware people, especially in European countries such as Germany where the Green party is going strong and we are already warned about the environmental impact of standby devices in elementary school. Regardless of their technical knowledge, such people will be put off by not being able to properly shut off, or having to jump trough hoops to do so. They will think that GNOME doesn't care about the environment. I don't want our wonderful community to make that impression. I don't want to start yet another flame war with this message (please, let's be sensible and respectful when discussing this). Neither do I want to denounce the design team; in fact, I greatly respect the design team for the many things it has done to make GNOME 3 the awesome piece of software that it is today, and that it will be tomorrow. I also don't want to throw everybody from the design team in the same pot: there are GNOME designers that are sympathetic towards some kind of compromise, as the discussion around bug #652183 [1] reveals. However, I feel that the current situation is not right, and that *something* has to be done to reach a solution that combines a high degree of usability with easily accessible ways to act environmentally responsible. I honestly think that the behaviour of those buttons is a separate issue from whether they should be configurable or not. True. As I said, I'm not looking for configurability, but for an overall solution that allows to both suspend and power down. Thanks for the kind words. :) You're welcome. :) Regards, Denis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On 01/09/11 14:41, Cosimo Cecchi wrote: Hi Federico, Hi Cosimo, On Wed, 2011-08-31 at 16:26 -0500, Federico Mena Quintero wrote: Can we please think about it as does Tracker allow me to implement an innovative application that wasn't possible before rather than is Tracker useful for Gnome? Something like Documents would be a lot harder to implement without Tracker's help. Interesting, but actually we also want a more file-less approach to the desktop without having to worry about where things are stored. Tracker does help accomplish this to some extent. Quite often I spent time worrying about where files are saved or where I can find them and it's a huge waste of time IMO if the desktop can facilitate this for me in a more economic way. Anyway most of the questions have been answered already by Martyn and Jasper, so I only have a couple of points. - Are we storing full-text indexes in the same database? Right now Documents doesn't use the full text search capabilities of Tracker. There are some interesting ideas on the roadmap here too, we've considered updating to FTS-4 (currently -3 is in use) - the impact should be insignificant to users of Tracker and in some cases performance would increase impressively according to what's boasted of the technology. There is also room for improvement there in Tracker, it's the least developed aspect of the project right now. Certainly features like snippet support can be improved to allow apps to show snippets of text found through a query (currently problematic translating between coordinates in stored text and the actual file itself, but not insurmountable). - Are we storing non-metadata (e.g. contacts) in the database? Documents makes use of the contact ontologies to display author information for indexed document files, and the GDocs miner stores there the same author information as provided by the server. These are usually triples in the format Yea, we do with documents we find too. Which makes sense. mailto:foo@bar a nco:Contact mailto:foo@bar nco:fullname Foo Bar urn:my-resource nco:author mailto:foo@bar The Contacts application doesn't store or read anything in Tracker as far as I know, but goes through libfolks. It would be really nice to have integration here IMO. I heard that libfolks works with Tracker, but to what extent, I don't know. - Is Tracker well-maintained now that Nokia is switching to something else? (I'm not sure if this is the right question, but something along those lines.) I have to say the Tracker team has been very responsive to my questions, and bugs got quickly fixed when I reported them. :) -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On 1 September 2011 15:05, Denis Washington den...@online.de wrote: Sounds interesting, though there is still the discoverability issue: you would have to know that a long button press powers off, and that pressing the power button gives you a shutdown method not accessible from the shell. (In fact, there are still a surprising number of people who still think that you must never ever touch the power button or risk your computer's health otherwise.) A solid and reliable behavior should also make it easier to have good and explicit documentation about stuff such as this. Rui ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On Thu, 2011-09-01 at 14:22 +0100, Allan Day wrote: Hey Denis! On Thu, Sep 1, 2011 at 1:18 PM, Denis Washington den...@online.de wrote: Am 01.09.2011 11:34, schrieb Frederic Peters: Hello all, This is 3.1.90, and it's out! It's the first beta of what will be GNOME 3.2, enjoy it while it's time, the next beta (3.1.91) will arrive next week. I saw this in the release notes of gnome-control-center: Power: - Remove power and suspend buttons config (Bastien Nocera) (#652183) (#657068) I am sad. Oh dear, don't be sad! The intent behind those changes is to ensure consistency and predictability. If we know what the behaviour of the hard buttons is going to be, we can produce better designs elsewhere and it is easier to provide users with advice and guidance. Also, we really want to be able to specify separate long and short button press actions for the hard power button (like on a mobile phone). It is hard to accommodate that kind of behaviour within a set of preferences that are easy to understand. I just want to be clear for the docs. What is the behavior of each of these two buttons? And doing something on long-press is just the goal, but not actually implemented for 3.2? Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On 09/01/2011 11:06 AM, Shaun McCance wrote: I just want to be clear for the docs. What is the behavior of each of these two buttons? And doing something on long-press is just the goal, but not actually implemented for 3.2? Long-press on power button immediately cuts power to the machine, and will always do that, because that's hardcoded into the motherboard. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.2 Blocker Report for week 35
Data taken from Bugzilla (bug reports with GNOME Target field set): https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOcf_gnome_target=3.2 Total number: 15 bugs. Comments (e.g. important issues that are missing in this list), status updates, and help (patches or reviews) very welcome! empathy: Add a MC gnome-online-accounts plugin https://bugzilla.gnome.org/show_bug.cgi?id=652543 This is done in a separate branch and work in progress. gnome-control-center: Network: custom connections don't show up in the list https://bugzilla.gnome.org/show_bug.cgi?id=645094 There is an old patch by hadess available. gnome-control-center: network: implement options ourselves https://bugzilla.gnome.org/show_bug.cgi?id=645003 gnome-control-center: Add support for missing timezones https://bugzilla.gnome.org/show_bug.cgi?id=644782 gnome-menus: Tools to perform system administration should be available in the menus somehow https://bugzilla.gnome.org/show_bug.cgi?id=645061 Patches available in the report. gnome-shell: gnome-screensaver and activities overview https://bugzilla.gnome.org/show_bug.cgi?id=609959 gnome-shell: Add brightness control to system icons https://bugzilla.gnome.org/show_bug.cgi?id=644168 gnome-shell: Everybody freeze! smooth xrandr transitions https://bugzilla.gnome.org/show_bug.cgi?id=644230 Patch available and awaiting review. gnome-shell: gnome-shell 3.2 feature/UI freeze tracker https://bugzilla.gnome.org/show_bug.cgi?id=657077 This metabug currently has four reports open. All four of them have patches attached. gnome-shell: Sound status: Use Alt to show default input/output https://bugzilla.gnome.org/show_bug.cgi?id=645798 gnome-utils: Port to GSettings https://bugzilla.gnome.org/show_bug.cgi?id=632429 Patch available that needs more work. libgnomekbd: layout indicator issues https://bugzilla.gnome.org/show_bug.cgi?id=642703 Patch available awaiting review. metacity: Migrate to GSettings https://bugzilla.gnome.org/show_bug.cgi?id=621204 Big patch available awaiting review. mutter: switching between single and multi monitor puts all windows in one desktop https://bugzilla.gnome.org/show_bug.cgi?id=645408 Patch available and reviewed, needs an update. totem: totem has dependency on mx https://bugzilla.gnome.org/show_bug.cgi?id=655590 Note that migrating evolution-data-server to GSettings has been postponed to 3.4: https://bugzilla.gnome.org/show_bug.cgi?id=635379 = For the records, we still have quite some open so-called important bugs from the 2.91 times that should get fixed but don't block the release. I will again list them here: cheese: Cheese is not able to do live theora encoding https://bugzilla.gnome.org/show_bug.cgi?id=564957 evince: remove NoDisplay=true https://bugzilla.gnome.org/show_bug.cgi?id=634245 Evolution: Don't use a status icon in evolution-alarm-notify https://bugzilla.gnome.org/show_bug.cgi?id=633297 gnome-control-center: add and remove printers https://bugzilla.gnome.org/show_bug.cgi?id=640734 gnome-control-center: network: add a way to 'forget' wireless connections https://bugzilla.gnome.org/show_bug.cgi?id=68 gnome-control-center: don't show Disconnected when cable is plugged in but device is off https://bugzilla.gnome.org/show_bug.cgi?id=646029 gnome-icon-theme: some rtl variants needed https://bugzilla.gnome.org/show_bug.cgi?id=641844 gnome-shell: Dash items on the overview requires a meaningful name https://bugzilla.gnome.org/show_bug.cgi?id=644255 gnome-shell: Calendar day names and all day badly ellipsized in French https://bugzilla.gnome.org/show_bug.cgi?id=645693 gnome-shell: Clicking on Open Calendar in GNOME Opens Evo's Mail View,https://bugzilla.gnome.org/show_bug.cgi?id=644077 gnome-shell: show message tray when the user is inactive https://bugzilla.gnome.org/show_bug.cgi?id=643014 gnome-shell: battery icon is a spaz when unplugging power cord https://bugzilla.gnome.org/show_bug.cgi?id=646284 gnome-shell: Make sure we always use an icon for the message tray source https://bugzilla.gnome.org/show_bug.cgi?id=630760 gnome-shell: separate banner and summary modes https://bugzilla.gnome.org/show_bug.cgi?id=636838 gnome-themes-standard: HighContrastInverse: missing control-center icons https://bugzilla.gnome.org/show_bug.cgi?id=644003 gnome-themes-standard: HighContrast: missing stock icons https://bugzilla.gnome.org/show_bug.cgi?id=644001 gnome-themes-standard: HighContrastInverse: missing stock icons https://bugzilla.gnome.org/show_bug.cgi?id=644004 gnome-themes-standard: HighContrast: missing control-center icons https://bugzilla.gnome.org/show_bug.cgi?id=644000 gtk+: No way to programmatically update visual state of a button https://bugzilla.gnome.org/show_bug.cgi?id=610515 gtk+: [gnome-terminal] When using theme colors,https://bugzilla.gnome.org/show_bug.cgi?id=640240 gtk+:
Re: GNOME 3.2 Blocker Report for week 35
On Thu, 2011-09-01 at 18:50 +0200, Andre Klapper wrote: Data taken from Bugzilla (bug reports with GNOME Target field set): https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOcf_gnome_target=3.2 Total number: 15 bugs. Comments (e.g. important issues that are missing in this list), status updates, and help (patches or reviews) very welcome! empathy: Add a MC gnome-online-accounts plugin https://bugzilla.gnome.org/show_bug.cgi?id=652543 This is done in a separate branch and work in progress. gnome-control-center: Network: custom connections don't show up in the list https://bugzilla.gnome.org/show_bug.cgi?id=645094 There is an old patch by hadess available. There isn't. snip totem: totem has dependency on mx https://bugzilla.gnome.org/show_bug.cgi?id=655590 That won't be fixed, as the clutter-gst work wasn't done. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 Blocker Report for week 35
On Thu, 2011-09-01 at 17:56 +0100, Bastien Nocera wrote: gnome-control-center: Network: custom connections don't show up in the list https://bugzilla.gnome.org/show_bug.cgi?id=645094 There is an old patch by hadess available. There isn't. Oops, true. Sorry, I think that refered to another bug in the list that I don't remember right now (no time to get through the list again). andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
Denis Washington den...@online.de a écrit: True. As I said, I'm not looking for configurability, but for an overall solution that allows to both suspend and power down. And to hibernate, please. -- Dodji ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 Blocker Report for week 35
Le jeudi 01 septembre 2011, à 18:50 +0200, Andre Klapper a écrit : gnome-menus: Tools to perform system administration should be available in the menus somehow https://bugzilla.gnome.org/show_bug.cgi?id=645061 Patches available in the report. (Note that the tools are available in the Other category right now, so I'm not sure this is a blocker by itself) The current suggestion is to add a Settings category in the menus; however, I'm unsure how well this works with the fact that it won't show what's in the gnome-control-center... Any opinion? The alternative is to just leave Other, and push people to move the items there in more appropriate categories. 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: Confused about the release
On Thu, 2011-09-01 at 11:25 +0200, Frederic Peters wrote: Documents will just be a preview release, it shows the direction, nothing more, nothing less, I don't think it's worth including it in the desktop help for 3.2. https://bugzilla.gnome.org/show_bug.cgi?id=657520 Documents is on the dash by default. That's strange for something we're calling a preview and not including in the help. (Side note: I'm mildly bemused that we don't include our official web browser in the favorites list of our showcase software.) -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 Blocker Report for week 35
On Thu, 2011-09-01 at 19:01 +0200, Andre Klapper wrote: On Thu, 2011-09-01 at 17:56 +0100, Bastien Nocera wrote: gnome-control-center: Network: custom connections don't show up in the list https://bugzilla.gnome.org/show_bug.cgi?id=645094 There is an old patch by hadess available. There isn't. Oops, true. Sorry, I think that refered to another bug in the list that I don't remember right now (no time to get through the list again). Probably the timezone one. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Confused about the release
On Thu, Sep 1, 2011 at 1:31 PM, Shaun McCance sha...@gnome.org wrote: (Side note: I'm mildly bemused that we don't include our official web browser in the favorites list of our showcase software.) https://bugzilla.gnome.org/show_bug.cgi?id=650616 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On Thu, Sep 1, 2011 at 12:24 PM, Bastien Nocera had...@hadess.net wrote: On Thu, 2011-09-01 at 11:17 -0400, Dan Winship wrote: On 09/01/2011 11:06 AM, Shaun McCance wrote: I just want to be clear for the docs. What is the behavior of each of these two buttons? And doing something on long-press is just the goal, but not actually implemented for 3.2? Long-press on power button immediately cuts power to the machine, and will always do that, because that's hardcoded into the motherboard. See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. As someone misfortunate enough to have used a WM phone for a few months I don't see what's so bad about the classic behaviour (for the lucky ones that may be unaware, I basically had to manually remove the battery every other week to recover from an OS crash). Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 Blocker Report for week 35
libgnomekbd: layout indicator issues https://bugzilla.gnome.org/show_bug.cgi?id=642703 Patch available awaiting review. Actually that patch was committed long ago. Will close the bug now. Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on extensions.gnome.org security
On Wed, 2011-08-31 at 17:16 -0400, Jasper St. Pierre wrote: [...] On Wed, Aug 31, 2011 at 4:32 PM, Owen Taylor otay...@redhat.com wrote: The idea of a GNOME Shell extension is to let the GNOME community build on top of the GNOME Shell code base, to tweak, to customize, and to prototype new GNOME features and behaviors. GNOME Shell extensions aren't sandboxed, and sandboxing them is fundamentally hard because shell extensions are defined as arbitrary tweaks to GNOME Shell. GNOME Shell is in the position to do such things as add global keybindings or read screen content, thus shell have the same capabilities. I think that there should at least be some attempt to try and do limited, but important sandboxing like you cannot write to any files except in storage that the extension system has allocated for you, you are not allowed to spawn any applications, you are not allowed to open any sockets or you are not allowed to make gsettings tweaks except out of the schemas that I give you. Unfortunately, I doubt this is possible with the current state of gjs/gobject-introspection, but I think it's worth investigating. I'm not all that optimistic about this - on one hand, extensions do need to be able to do dangerous things - I'd consider an extension that modified or replaced the onscreen keyboard legitimate - and once you can act as the onscreen keyboard, you can type arbitrary stuff into a terminal. And on the other hand, the GNOME API's aren't designed to be protected against users with bad intent. E.g., in GTK+ if you change the widget hierarchy out of a ::paint signal, you'll crash GTK+. So I think it would be hard to make a truly bulletproof system - Java was designed for this from the start and there are still problems popping up. The one thing you might be able to achieve this way would be to make ill-intentioned extensions more obvious in code review; it might be worth exploring in this direction, but I don't see it as being an alternative to review of extension code. - Add some capability for self-healing to the extension update mechanism. There's not much we can do if an extension once run installs a back-door on the user's system, but we should be able to remove known bad extensions through the update process, even if the extension doesn't have proper update metadata. I'm unsure about this -- I don't think that an update or blacklist mechanism should touch anything that the user or a system administrator installed themselves. Of course, if we try to record which extensions got installed through the website, even with just a simple I like the simplicity of saying I have alternative-alt-tab 0.4 is there an update?, rather than having the possibility that you might have that extension installed, but from a different location, or with something funny in its metadata file. That would only apply to extensions installed in the user's directory, not systemwide, presumably. I don't feel strongly here, but I'd certainly vote in favor of simplicity and centralization. [..] If all that the plugin can do is say install plugin GUID x-y-z, whch that then triggers a download from https://extensions.gnome.org and shows a dialog, then any exploits along this line should at least be detectable to moderately sophisticated users, who will hopefully then report them so they can be fixed. Right now you pass the plugin an URL to a manifest file, so it's not hardcoded to seek out the URL based on extensions.gnome.org. The idea here was that if we needed to offload the servers with the extension data to a CDN, we wouldn't have to make the users upgrade their distributions. A hard requirement for me is that a HTML-injection problem on extensions.gnome.org can't make the plugin download and install random code from a random site. The two ways I can think of to address this are: A) Make the plugin only tell the downloader what to download and not to download it from. B) Sign extension dowloads with a gnome.org private key. A) is considerably simpler. B) offers some more flexibility. (You can still handle offload in the A) case by doing redirects.) - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on extensions.gnome.org security
A) Make the plugin only tell the downloader what to download and not to download it from. You still need a key - even if the https:// authentication for gnome.org itself to prove the connection is to the correct site. B) Sign extension dowloads with a gnome.org private key. A) is considerably simpler. B) offers some more flexibility. (You can still handle offload in the A) case by doing redirects.) Another way to address B is to sign an index of locations of and hashes for the extensions rather than signing each extension individually. Might be easier to operate but with B you could use a heirarchy of keys (gnome-signer) which would let the installer see who (one or many) signed the package having reviewed it, and also allow revocations. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notes on extensions.gnome.org security
On Wed, 2011-08-31 at 22:35 +0100, Alan Cox wrote: Of course, Linux users run unsandboxed code with arbitary capabilities every day - applications, for example. So the security question with GNOME Shell extensions is not how we can do the almost impossible job of sandboxing them, but how we can build up layers of social, user interface, and technical protections to make them not an attractive deployment mechanism for malware. I would say the question is both that and how you sandbox them to some extent in the same way as you sandbox apps with SELinux. That requires sensible architecture decisions about isolation. An extension that wants to look at my ssh keys for example is detectable as anomalous behaviour. - Don't have automatic deployment for extensions.gnome.org changes but make it a manual process. - Restrict the set of users who can commit to the extensions.gnome.org code module. - Sign 'approved' extensions with keys which are not kept on a public system. Yes. In theory signatures can offer a layer of security that is independent of the security of the hosting of extensions. It's hard for me to wrap my head around a way to make that practical, if we want to be able to review and approve extensions through the web UI. Schemes I can come up end up with end up with something like: - Reviewers download and review extensions locally, then sign them with their GPG key. - An adminstrator takes the signed extensions, checks the reviewers signature and then adds the official GNOME signature. That would be very secure, but it also creates manual steps and points of failure that would likely make the system just not work in practice. We shouldn't forget either that our opinion about whether an extension is safe can change over time. A signature only means that that exact code base passed review at one point in time. But we later could discover problems with it. Another reason I tend to like centralization rather than only relying on embedded signatures. If all that the plugin can do is say install plugin GUID x-y-z, whch that then triggers a download from https://extensions.gnome.org and shows a dialog, then any exploits along this line should at least be detectable to moderately sophisticated users, who will hopefully then report them so they can be fixed. Are the existing mime type and helpers not sufficient ? In terms of these security goals, I think the mime type system could be adapted - that is, we could define a mime type text/x-gnome-shell-extensions-install-manifest, and when you clicked on it, the right things happen. The plugin mostly is about improving the UI beyond that - being able to mark extensions you alread have installed, be able to disable them from the web, etc. However, this does not correspond to our overall goals for extensions: we want a very clear distinction between extensions and applications, we want extension installation to be under the control of the user and not the system builder, and we want to encourage a community of extension creation that doesn't involve an extra layer of distribution specific packaging. In which case you probably do also want a system wide ability to turn off users adding extensons, especially unsigned ones, for business environments. It should be already possible to lock down the enabled-extensions gsettings, so the main thing would be adapting the UI to make it clear to the user that it was the case. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rethinking GnomeGoals
Le 21/08/2011 18:53, Djohn Heist a écrit : I redid the template file and made it into an matrix so all modules and goals share the same page. It is inspired by http://people.gnome.org/~fpeters/299.html you can have a look at it on https://live.gnome.org/DjohnHeist I'm not sure this would be a good change. Several modules on the same page make the wiki page harder to edit. Which is why the template page exists: it serves as a basis for each new goal state. Moreover what you're doing can't become a new template: you would need to merge the real state of things with your modified template each time you're adding or removing a goal, or add/remove a module. And merging wiki data would pretty much be a nightmare. Currently, we're also able to keep the status of an old goal. But with your matrix, this means your file would grow forever. No, the matrix idea is not a good one here. Frederic Peters only did that on the page you cite because that page wasn't on the wiki, but was automatically generated. And this is what should be done, in fact. Let me explain: almost all the data we want is on the bugzilla. Only little data is relevant on the wiki: only the stuff that would change often, like the guidelines to achieve the goal for example that are heavily modified before they are ready to become a real goal. But a goal's status should be extracted from bugzilla. This would be best done IMHO done by using a attaching a special bugzilla keyword to the bug to identify to which goal it belongs (using the goal's name to compare it to the bug's title would forbid us to rename goals). I don't know though if bugzilla supports something like gnome-goal:CorrectDesktopFiles as a valid bug keyword. Otherwise, ggCorrectDesktopFiles would make it. Then you would need to perform a bugzilla request and generate on-the-fly the status of all the bugs that share that keyword. The only problem I see there is than if no bug has been open for a specific module, we can't know if the status of the bug for this module is todo or not needed, unless we automatically open bugs against the modules and triage them afterwards. Automatically opening the bugs may be seen as pollution of the bugzilla database, but sometimes it's unclear if a goal applies to a specific module. So maybe it wouldn't be a bad idea. By doing this you would be able to get a goal's status across all modules, automatically know if a patch has been posted. And the modules list and the modulesets could be parsed from the official modulesets in jhbuild. That way you could even follow new modules as they are included in GNOME. Doing this may require a good amount of programming, so if your initial aim was just to update the template file, then use the original template and update the names of modules and modulesets according to those of GNOME 3, but not in a matrix. Hope this helps. -- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On Thu, Sep 1, 2011 at 10:55 PM, Evandro Giovanini efgiovan...@gmail.com wrote: On Thu, Sep 1, 2011 at 12:24 PM, Bastien Nocera had...@hadess.net wrote: See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. As someone misfortunate enough to have used a WM phone for a few months I don't see what's so bad about the classic behaviour (for the lucky ones that may be unaware, I basically had to manually remove the battery every other week to recover from an OS crash). On my laptop, I encounter enough hard lockups while testing software that the long-press behaviour of the power button is essential for me. I don't want to have to flip my machine over and take out the battery everytime. For all I know, doing that repeatedly might even damage the device. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. Unlikely. Users like a way to get their system back into sane order. Another reason a software option to power off is useful - it cleans up any crap, leaks etc. In a perfect world it isn't needed, but in this particular one it is. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.1.90 beta released!
On Fri, 2011-09-02 at 00:18 +0530, Nirbheek Chauhan wrote: On Thu, Sep 1, 2011 at 10:55 PM, Evandro Giovanini efgiovan...@gmail.com wrote: On Thu, Sep 1, 2011 at 12:24 PM, Bastien Nocera had...@hadess.net wrote: See https://bugzilla.gnome.org/show_bug.cgi?id=657496 I hope we get some hardware that's a bit more advanced than this 1990's behaviour in the future. As someone misfortunate enough to have used a WM phone for a few months I don't see what's so bad about the classic behaviour (for the lucky ones that may be unaware, I basically had to manually remove the battery every other week to recover from an OS crash). On my laptop, I encounter enough hard lockups while testing software that the long-press behaviour of the power button is essential for me. I don't want to have to flip my machine over and take out the battery everytime. For all I know, doing that repeatedly might even damage the device. In the worst case, you still can use the Magic SysRq key. http://en.wikipedia.org/wiki/Magic_SysRq_key -- Germán Póo-Caamaño http://people.gnome.org/~gpoo/ 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
Re: GNOME 3.1.90 beta released!
On Fri, Sep 2, 2011 at 12:40 AM, Germán Póo-Caamaño g...@gnome.org wrote: On Fri, 2011-09-02 at 00:18 +0530, Nirbheek Chauhan wrote: On my laptop, I encounter enough hard lockups while testing software that the long-press behaviour of the power button is essential for me. I don't want to have to flip my machine over and take out the battery everytime. For all I know, doing that repeatedly might even damage the device. In the worst case, you still can use the Magic SysRq key. http://en.wikipedia.org/wiki/Magic_SysRq_key They often don't work in case of kernel lockups, or Xorg problems (which often lockup the kernel). They've worked maybe half the time I've had a system lockup. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
