Re: Bugfix in gnome-sound-recorder

[David King]

Hi Meg

On 2015-10-29 20:04, meg ford  wrote:

Last week I got a report about a bug which broke the waveforms in
gnome-sound-recorder in 3.18.1. The problem was caused by improvements
which made GStreamer faster and uncovered an uncaught exception in my code.
Since 3.18.1 was the last release I made for 3.18, and I've never had to do
a bugfix, I don't know how to proceed. Is there some way to distribute a
version with the patch? Do I need to file patches to downstream versions?


The 3.18.2 release is scheduled for 2015-11-09, according to 
https://wiki.gnome.org/ThreePointNineteen


Depending on how serious you think the bug is, you can make a new 
tarball release now, or just wait until the next stable release. I have 
added the patch to the Fedora package, and it is easy to update to a 
tarball release when that happens (either for 3.18.2 or 3.18.1.1 or 
similar).


For serious issues, it can be worth emailing 
:


https://mail.gnome.org/mailman/listinfo/distributor-list

That is generally the place to email if there is some major 
(ABI-breaking, for example) change that could affect other projects.


Thanks for taking the time to notify people about the bug and fix!

--
http://amigadave.com/


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: java-atk-wrapper maintainership

[David King]

Hi

On 2014-10-17 16:37, Magdalen Berns m.be...@thismagpie.com wrote:

I would like to support the new java wrapper maintainer, Alejandro with the
task of maintaining java-atk-wrapper since the whole module needs updating
having been abandoned back in 2011 until recently when I submitted a patch
to allow it to be built successfully on the latest version of GNOME[1,2]. I
also updated the doap to reflect reality and conform to the latest doap
standard used by GNOME[3]


As Alejandro is the maintainer, you should ask him, rather than 
desktop-devel-list, if you want to become a maintainer.



The first commit since 2011, were just this week and, it's fair to say that
the module has generally got a bit old and suboptimal over time.[4]

I reckon it would really be great to put a bit more brainspace and time
into improving things for java(by making use of what the most current java
API can offer and ensuring that the module is wrapping the latest interface
methods. For example, at the moment the text interface is completely
outdated and this is likely to create problems for users if it is not dealt
with.[5]


It is promising that you have ideas and want to contribute to the 
project, but you do not need to be a maintainer to accomplish those 
goals.



Provided there are no objections, I will add myself to the doap file and
maintain this module.


As there is an active maintainer, there is no need for someone on this 
mailing list to approve of you becoming a maintainer. You would be 
better off finding out from Alejandro what he thinks.


There are several open bugs for java-atk-wrapper:

https://bugzilla.gnome.org/buglist.cgi?product=at-spibug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Java%20ATK%20Wrapper

Fixing some of those bugs would be an excellent way towards 
demonstrating that you would make a good module maintainer. 


--
http://amigadave.com/


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[David King]

Hi Olav

On 2014-08-03 01:33, Olav Vitters o...@vitters.nl wrote:

Aside from above I also slightly changed the wiki.gnome.org header
(e.g. shows RecentChanges+Schedule again). The Schedule is IMO quite
important.


Excellent, I had been missing that since the redesign! (Of course, 
thanks for all the DOAP changes too.)


--
http://amigadave.com/


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Translation commits pushed when rolling a tarball

[David King]

On 2014-08-01 23:40, Sébastien Wilmet swil...@gnome.org wrote:

On Fri, 2014-08-01 at 18:40 +0200, Kalev Lember wrote:

It's not really much of a problem for me to run
'make distcheck' once more to pick up additional translation goodness.


For stable releases taking the latest translations is important, but for
unstable releases it's not a big deal if the translation is for the next
beta.

Making releases is not the funniest part of a maintainer work, even if
push conflicts are rare (at least for me), the fact that I know it can
happen doesn't put me in a comfortable position when rolling a tarball
(it's more on the psychological side).


It is not a problem for me, neither a psychological or an actual one (I 
cannot remember a time when a translation commit has been pushed while I 
ran distcheck, but conceivably it could have happened), so I would 
rather keep the behaviour simple, as it is now.


--
http://amigadave.com/


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Correct .doap file syntax for the name tag

[David King]

On 2013-08-22 12:49, Olav Vitters o...@vitters.nl wrote:

On Thu, Aug 22, 2013 at 12:28:43PM +0200, Andrea Veri wrote:

No, sorry for not pointing that out on my previous email, you can use a
name tag of your choice but it would be simply awesome to have all the
GitRepositories tags in place.


GitRepositories is really not needed. A script adds that, there is no
need to add such information IMO.


The build-repo-list script adds the GitRepository property to the DOAP 
file at https://git.gnome.org/repositories.doap but does not add the 
same information to the DOAP file in each repository.


I think that the DOAP files in each repository should be the canonical 
source of project metadata, so that moving the injected data from 
repositories.doap to individual modules should be a goal. This has the 
(slight) benefit that public clones of the repository will then contain 
the upstream location of the source.


However, it is a minor thing, and the current mirror script works 
without it. None of the current sysadmin scripts use the GitRepository 
property, other than injecting it into repositories.doap.


--
http://amigadave.com/


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: translator to developers

[David King]

Hi Pavel

On 2013-03-10 17:08, Pavol Klačanský pa...@klacansky.com wrote:

I do translate some pieces into Slovak language and I would like to ask
to stick to this rules:


There are already guidelines for developers:

https://live.gnome.org/TranslationProject/DevGuidelines

Maintainers and developers are encouraged to follow those guidelines:

https://live.gnome.org/MaintainersCorner


1. when string is used more than once in a project, hence (in .po file
only once), always add context to each occurrence


You missed a “… if the strings are used in different contexts” at the 
end of that guidelines. See:


https://live.gnome.org/TranslationProject/DevGuidelines/Translation%20contexts

It seems like bad advice to suggest that identical strings should have 
different contexts as a matter of policy, but I guess that is not what 
you meant.



2. plural forms should be everywhere in case you have %d bytes or
something like that


https://live.gnome.org/TranslationProject/DevGuidelines/Plurals


3. please, do add comments wherever it is necessary (from point of view
of translator)


https://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments


…
You will save us and yourselves a lot time, because then we do not need
to report so many bugs to request comment or context.


Developers often rely on bug reports from translators to point out 
problems with translatable strings, especially in the cases that you 
mentioned. Please continue to report bugs for any issues that you find, 
and I am sure that developers will be happy to improve their projects.


--
http://amigadave.com/


pgp_VQQgMauAJ.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[David King]

On 2013-02-13 11:58, Andre Klapper ak...@gmx.net wrote:

When I checked three months ago, 79 of 654 non-archived Git modules had
no DOAP file at all. 287 out of 575 modules with a DOAP file had an
entry for bug-database. GNOME does not even list bug-database in
https://live.gnome.org/action/recall/Git/FAQ?action=recallrev=29#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F


I just added a bug-database item to that DOAP template.

Should we have a GNOME Goal to tidy up the DOAP files and add a minimum 
set of recommended fields? It might not be a great deal of use, so just 
some better guidance on the wiki would probably be sufficient.


--
http://amigadave.com/


pgpHlNCm61kgi.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using the Unicode ellipsis (…) instead of three periods

[David King]

On 2012-12-04 09:08, Philip Withnall phi...@tecnocode.co.uk wrote:

On Mon, 2012-12-03 at 22:01 -0600, Ted Gould wrote:

On Mon, 2012-12-03 at 19:09 -0500, Jeremy Bicha wrote:
 I think it's time that we move away from using three periods (...) to
 represent the ellipsis and instead use the Unicode character (…).

We've been trying to do this on the Unity Indicators and I wrote a small
automake fragment to test for them.  It's a little bit hacky, but it
works and makes sure we don't regress.  I'd love for it to get used and
improved in other projects.

http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.04/view/head:/tests/Makefile.am.strings


That looks really useful! Perhaps it could get included in gnome-common
and then used in GNOME projects?


Looks good to me! Ted or Philip, can you file a bug against 
gnome-common? If there is to be a GNOME Goal for this (and the other 
checks, such as ‘spaces before ellipsis’) it would be good to get 
gnome-common to offer some assistance.


--
http://amigadave.com/


pgpfEuUkvKtR2.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

EasyTAG has moved to gnome.org

[David King]

I have used EasyTAG for many years to edits tags and rename files in my 
music collection, and I was sad to see that the project had languished 
somewhat on SourceForge. However, after some discussions with the 
maintainer, Kip Warner, I helped to move the project over to GNOME 
infrastructure:


http://projects.gnome.org/easytag/
http://git.gnome.org/browse/easytag/
https://bugzilla.gnome.org/browse.cgi?product=easytag
https://mail.gnome.org/mailman/listinfo/easytag-list

There is currently no release containing all the new changes that have 
been merged over the last week, but there should be one soon. Many 
thanks to Andrea Veri and Andre Klapper for the mailing list and 
Bugzilla migration and advice.


Bug reports, suggestions and help are most welcome - happy tagging!

--
http://amigadave.com/


pgpSJwrMySDcX.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[David King]

On 2012-11-21 20:53, Raphaël Jacquot sxp...@sxpert.org wrote:

I don't talk often on this list, for lack of available time, but have the 
following to say :

The decision is all nice and well. however this will force people that don't 
have the latest and greatest accelerated hardware to switch to something else.
most PCs that are more that 2 years old are probably out of the game.


This was covered in the ‘Description’ section of the 
DropOrFixFallbackMode page that Matthias linked to:


https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode

“Since the release of 3.0, a technology called llvmpipe has allowed for 
fast software rendering, lowering the need for the fallback mode. 
However llvmpipe doesn't currently work on some architectures (ppc, 
s390, arm?--ARM (hf) works-shawnl) and might not work in some 
non-Linux-based OS (OpenBSD support is not there, for instance).”


If you would care to test llvmpipe with GNOME Shell and report back on 
the performance, I am sure that would be a useful data point for the
discussion. Personally, I use GNOME Shell on some hardware from 3 years 
ago and the (accelerated) performance seems fine.


--
http://amigadave.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-common updated with some explicit -Werror flags

[David King]

On 2012-11-02 15:33, Colin Walters walt...@verbum.org wrote:

I checked everything in the current gnome-ostree 3.8 manifest builds,
but there is likely more out there.


Hi Colin!

Firstly, thanks for testing this and helping to get it in good shape, as 
well as for starting the initial discussion.



If you hit anything, please comment
on the bug and we can work out whether we should drop anything from the
base set of -Werror=foo flags.


Another possible workaround is to pass minimum as an argument to 
GNOME_COMPILE_WARNINGS (or via ./configure 
--enable-compile-warnings=minimum) as this builds with only -Wall 
added to the warning flags.


I would still be interested to hear about any problem with the 
-Werror=foo flags, of course.


--
http://amigadave.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: compiler warnings, -Werror, etc.

[David King]

On 2012-07-27 21:18, Philip Withnall phi...@tecnocode.co.uk wrote:

Furthermore, is there any reason why modules shouldn't be using
GNOME_COMPILE_WARNINGS? It would be great if we could standardise on
using it so that we can guarantee that the classes of bugs it detects
are highlighted (and perhaps eventually eliminated) in GNOME code.


I added a patch to Bugzilla for gnome-common which adds the warnings 
from libsoup that Colin pointed out:


https://bugzilla.gnome.org/show_bug.cgi?id=608953
http://bugzilla-attachments.gnome.org/attachment.cgi?id=219785

There is surely some room for improvement, but it seems like a good 
place to start.


--
http://amigadave.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes (was Re: 3.4 Features, final round)

[David King]

On 2011-11-08 08:57, Frederic Peters fpet...@gnome.org wrote:

Zeeshan Ali (Khattak) wrote:


On Mon, Nov 7, 2011 at 9:00 AM, Vincent Untz vu...@gnome.org wrote:
 Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit :
 + Boxes
   https://live.gnome.org/ThreePointThree/Features/Boxes
   → many commits, mclasen will push the developers to blog a progress report
     once they have something to show

 While Boxes look interesting, to me, it feels like it's just an
 application, and not a feature per se. And I'm not saying that in a
 negative way :-)

  You are correct in the sense that it is 'an' application and not 'a'
feature. It is more like 2 essential features combined in one:

1. Remote display: It is very common to own/having to deal with
multiple machines these days so many users really need ability to
easily connect to remote machines (virtual and real).


Talking about connecting to remote machines, how will Boxes coexist
with Vinagre? Do you expect its features to be available via Boxes by
3.4 time, or should both of them coexist for a while?

David, what's your take on this?


It looks like Boxes will be able to do everything that Vinagre can 
currently do, and more, by the time that 3.4 is released. If that is the 
case, I do not see a reason for Vinagre to coexist. Of course, Vinagre 
works right now, and if Boxes is not ready, it will still work, so it 
seems a good fallback for distributions.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: From here to apps

[David King]

On 2011-09-26 14:56, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote:

On Mon, Sep 26, 2011 at 1:09 PM, Frederic Peters fpet...@gnome.org wrote:

Speaking of Vinagre, it even has Implement some of the ideas from
GNOME desktop sharing/virtualisation design mockups on its roadmap
for 3.4 (see https://live.gnome.org/Vinagre/RoadMap).


To clarify, the parts of the Boxes design that I am most interested in 
implementing in Vinagre are the recent connections browser. The current 
behaviour involves a dialog, and makes it awkward to use Avahi to find 
remote desktops on the local network. The Boxes design makes this a lot 
more friendly. Of course, this is only in the roadmap for 3.4, it may 
not get implemented.



 I assume you are referring to Boxes here[1]. If you look at the
tentative designs, the UI is significantly different from that of
vinagre and virt-manager to justify writing of this UI from
scratch[2]. Apart from the UI, I don't see how much of vinagre code
could be useful to us since AFAIK most of the functionality is
provided by spice-gtk  (Marc-Andre?). Moreover, vinagre doesn't do any
VM management, which is a significant part of Boxes idea. There is a
conflict with virt-manager in that area (as you noticed) but we are
working closely with Daniel P. Berrange on the framework side so that
most (if not all) of this 'conflict' is limited to UI only.


I agree pretty strongly with this. The Vinagre plugins, for example VNC 
and SSH, are directly tied to many aspects of the UI, and therefore 
changing it would mean rewriting most of Vinagre from scratch anyway.  
Also, I do not think that Vinagre will suddenly grow the ability to be a 
generic virtual machine application. It handles the remote desktop 
client use case pretty well, and some of that overlaps with Boxes, which 
I do not see as a problem for the moment.



--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] https://live.gnome.org/Design/Apps/Boxes
[2] Since many components of UI are common with Documents, I intend to
re-use/steal code from there.


--
http://amigadave.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: install-module / ftp.gnome.org / master.gnome.org

[David King]

On 2011-03-02 13:46, Javier Jardón jjar...@gnome.org wrote:

On 2 March 2011 11:57, Vincent Untz vu...@gnome.org wrote:


First step: kindly ask maintainers to use dist-lzma in AM_INIT_AUTOMAKE
;-)


I think would be better dist-xz instead, as xz displaced the lzma
format some time ago [1]

[1] 
http://www.gnu.org/software/automake/manual/automake.html#The-Types-of-Distributions


This seems like another good reason to push the (proposed) autotools 
modernisation goal:


http://live.gnome.org/GnomeGoals/ModernAutotools

at least once someone adds the dist-xz suggestion to that page. ;)

As dist-xz was introduced in Automake 1.11, this would also seem like a 
good reason to push for requiring that version (or maybe 1.11.1 would be 
better, as it fixes a security bug in 1.11). Either that, or 
install-module could do the conversion server-side.


--
http://amigadave.com/ | dav...@openismus.com
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list