Re: Renaming gitg project file to GNOME Commits

[Hashem Nasarat via desktop-devel-list]

There's also https://github.com/indie-mirror/gnomit !

Crowded namespace!

On Wed, Oct 10, 2018 at 6:04 PM Hashem Nasarat  wrote:

>
> GNOME Git seems pretty reasonable. I'm not sure there's a large
> discoverability issue with "gitg" though. It shows up when I search "git"
> in GNOME Software...
> I don't know if we have a policy for "gnome front-ends to existing third
> party tools", but there's already a small precedence with
> https://github.com/vinszent/gnome-twitch#-gnome-twitch
>
> (Too bad https://github.com/bahmutov/ggit is a thing.)
>
> On Wed, Oct 10, 2018 at 5:50 PM Alberto Fanjul Alonso via
> desktop-devel-list  wrote:
>
>> Seing https://git-scm.com/downloads/guis and asumming  GNOME is a
>> desktop environment (GUI is supposed) maybe GNOME Git Tool, but tool is
>> little redundant here, that's why looking for something that this git GUI
>> Tool can do. Maybe GNOME Git Commits as it shows them (history) and creates
>> them.
>>
>> El mié., 10 oct. 2018 a las 23:26, Milan Crha via desktop-devel-list (<
>> desktop-devel-list@gnome.org>) escribió:
>>
>>> On Wed, 2018-10-10 at 08:34 +0200, Alberto Fanjul Alonso wrote:
>>> > On gitg we are considering to adopt GNOME Commits as project name.
>>>
>>> Hi,
>>> I'm used to gitk (which uses Qt, if I'm not mistaken). The gitg always
>>> meant to me a gtk+ variant "of the same". I never looked for the real
>>> reasoning behind the name (which you gave earlier).
>>>
>>> Can it work with anything else than git? I do commit to svn, I used to
>>> commit to cvs as well. There are several other version systems where
>>> users can "commit" their changes. I mean, "GNOME Commits" is too
>>> generic, too vague. "GNOME git viewer" might be more accurate, but not
>>> that fancy. I surely would not get rid of the 'git' word, especially
>>> when it's the only version system it can work with. When searching for
>>> 'git' in repositories, it would be nice to have git itself and "the
>>> viewer" shown together.
>>>
>>> Just my opinion.
>>> Bye,
>>> Milan
>>>
>>> ___
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Renaming gitg project file to GNOME Commits

[Hashem Nasarat via desktop-devel-list]

GNOME Git seems pretty reasonable. I'm not sure there's a large
discoverability issue with "gitg" though. It shows up when I search "git"
in GNOME Software...
I don't know if we have a policy for "gnome front-ends to existing third
party tools", but there's already a small precedence with
https://github.com/vinszent/gnome-twitch#-gnome-twitch

(Too bad https://github.com/bahmutov/ggit is a thing.)

On Wed, Oct 10, 2018 at 5:50 PM Alberto Fanjul Alonso via
desktop-devel-list  wrote:

> Seing https://git-scm.com/downloads/guis and asumming  GNOME is a desktop
> environment (GUI is supposed) maybe GNOME Git Tool, but tool is little
> redundant here, that's why looking for something that this git GUI Tool can
> do. Maybe GNOME Git Commits as it shows them (history) and creates them.
>
> El mié., 10 oct. 2018 a las 23:26, Milan Crha via desktop-devel-list (<
> desktop-devel-list@gnome.org>) escribió:
>
>> On Wed, 2018-10-10 at 08:34 +0200, Alberto Fanjul Alonso wrote:
>> > On gitg we are considering to adopt GNOME Commits as project name.
>>
>> Hi,
>> I'm used to gitk (which uses Qt, if I'm not mistaken). The gitg always
>> meant to me a gtk+ variant "of the same". I never looked for the real
>> reasoning behind the name (which you gave earlier).
>>
>> Can it work with anything else than git? I do commit to svn, I used to
>> commit to cvs as well. There are several other version systems where
>> users can "commit" their changes. I mean, "GNOME Commits" is too
>> generic, too vague. "GNOME git viewer" might be more accurate, but not
>> that fancy. I surely would not get rid of the 'git' word, especially
>> when it's the only version system it can work with. When searching for
>> 'git' in repositories, it would be nice to have git itself and "the
>> viewer" shown together.
>>
>> Just my opinion.
>> Bye,
>> Milan
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab update: Moving to the next step

[Hashem Nasarat]

On Thu, Dec 7, 2017 at 12:01 PM, Milan Crha  wrote:

>
>
> a) See the second comment of
>https://gitlab-test.gnome.org/mcrha/test/issues/2
>It shows like three lines of text (one line, then empty line, then
>third line). When you edit that comment you'll see I made it
>several lines, not only three - the interface is ignoring my
>Enter-s. Am I supposed to use some crazy tag when I want to divide
>paragraphs and/or write simple lines?
>

I was confused but figured out how to insert line breaks using Markdown:
just end the line with two spaces then a newline

For example this is on
a new line.

http://markdown-guide.readthedocs.io/en/latest/basics.html#line-return
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: User account for migrating Bugzilla issues to GitLab

[Hashem Nasarat]

Wow nice! I wonder if upstream gitlab would be also be interested in such a
bugzilla-to-gitlab migration tool.

On Mon, Nov 13, 2017 at 8:07 AM, Carlos Soriano  wrote:

> Amazing job Philip, those examples look really good with the review of the
> patches included.
>
> Agree with Emmanuelle, seems Alberto won't have much time for the time
> being so let's move it to our instance if Alberto agrees. You can create a
> repo on your own namespace with those changes and I will move it to /GNOME.
>
> Best
> --
> Carlos Soriano
> GNOME Foundation
> Treasurer, Board of Directors
>
> On Mon, Nov 13, 2017 at 1:43 PM, Emmanuele Bassi  wrote:
>
>> Thanks, Philip: this is much appreciated.
>>
>> Since Alberto won't likely have time to work on this for a while, and
>> since this code should live in GNOME's own GitLab instance, how about
>> we create a new repository there?
>>
>> Ciao,
>>  Emmanuele.
>>
>> On 13 November 2017 at 00:14,   wrote:
>> > Hi,
>> >
>> > I've spent the weekend hacking on Alberto's Bugzilla-to-GitLab migration
>> > script and I've made some nice improvements in the
>> readability/friendliness
>> > of the automatically generated issues, in my opinion. With everything in
>> > this merge request [1] I've got it in a state where I'm happy to start
>> > migrating issues for GJS from Bugzilla to GitLab.
>> >
>> > I also have a couple of GJS-specific changes which are here [2] in case
>> > anyone else is interested in copying them.
>> >
>> > One thing I'd like to check before I do that is whether it would be
>> possible
>> > to do the migration logged in as a "bugzilla-migration" user on GitLab,
>> for
>> > which I've opened an issue [3]. It would be a nice bonus to not have
>> myself
>> > auto-subscribed to every issue that is migrated :-) It seems like it
>> should
>> > be possible for a GitLab admin to create this account and, for example,
>> give
>> > out a time-limited access token to a maintainer who wanted to run the
>> > migration script.
>> >
>> > If the bugzilla-migration user had admin permissions, it looks like the
>> > script could even post comments as the user who originally made the
>> comment
>> > on Bugzilla, if that GitLab user exists. (On the other hand, it seems
>> risky
>> > to hand out access tokens, even time-limited ones, to an admin account.)
>> >
>> > Any GitLab gurus have thoughts on this?
>> >
>> > Here are some examples of what the tool's output now looks like, on the
>> > GitLab test instance:
>> > - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/75
>> > - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/77
>> > - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/70
>> > The full list is here [4].
>> >
>> > Regards,
>> > Philip C
>> >
>> > [1] https://gitlab.com/aruiz/gitlab-gnome-tools/merge_requests/9
>> > [2] https://gitlab.com/ptomato/gitlab-gnome-tools/compare/master...gjs
>> > [3] https://gitlab.com/aruiz/gitlab-gnome-tools/issues/20
>> > [4] https://gitlab-test.gnome.org/ptomato/gjs-test/issues?state=opened
>> >
>> >
>> > ___
>> > desktop-devel-list mailing list
>> > desktop-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>>
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fwd: Proposal: revisiting menus in Gnome

[Hashem Nasarat]

Thanks for writing this up, Greg! The pamel menu has always been a pet 
peeve of mine in GNOME. You've argued well why it hasn't worked out, and 
I hope the the design and gnome-shell teams engage with your ideas.


Couple things come to mind:

* Maybe you could add your ideas to the wiki under a candidate GNOME 
goal? https://wiki.gnome.org/Initiatives/GnomeGoals/


* Some design mockups would help understand some of your suggestions, 
like having icon buttons in the headerbar menu, and your comment about 
supporting AppIndicators in the panel menu.


* gedit, at least, changes its ui when it detects that there is no panel 
menu in the current desktop environment. It moves the app-wide menu 
items into the headerbar menu. This is workable, but I really like your 
idea of a Help> menu item group.

Gedit (updates ui): http://i.imgur.com/VDde5XE.png
nautilus (like most gnome apps, just shows icon button in top left): 
http://i.imgur.com/gCQ5jFy.png


* Firefox currently uses icons in the last row of their menu for help 
and quit. With the new redesign though I wonder what they've learned...
From a design screenshots: 
http://www.omgubuntu.co.uk/wp-content/uploads/2017/04/firefox-photon-main-menu.jpg
via 
http://www.omgubuntu.co.uk/2017/04/screenshots-firefoxs-photon-redesign-surface-online
	- it seems like they're moving away from the button group in the last 
row of the app menu.
	- They don't show Help being a submenu, but in the current version of 
firefox the Help icon indeed is a submenu so I think this might just be 
an oversight in the design screenshot.
	- they don't show Quit any more: this makes sense to me as the most 
common way of closing an app is just clicking the [x] in the titlebar. 
This makes it clear to me that we don't need to have 'Quit' in the 
headerbar menu.


* I'm unconvinced that duplicating the jumplist menu in the panel menu 
is the right way to go. I never use the jumplist options in GNOME. I 
asked my friend who uses Mac and iPhone, and she never uses the dock 
right-click jumplist on the Mac, or the pressure-activated app icon 
jumplist on the iPhone.


* For such seldom-used functionality, it seems wrong to me to dedicate 
space in the top pamel to that. I'd maybe propose as an interim, we can 
leave the functionality of the pamel menu as is, and merely duplicate 
Help and Preferences in the headerbar menu of apps. We can say the panel 
menu is deprecated and will soon go away, and then we can think about 
better utilizing the screen real estate instead of showing the app icon 
and panel menu. I don't think the panel has been well received, and has 
been the cause of much of the push-back from GNOME. Perhaps integrating 
something like https://github.com/jderose9/dash-to-panel would better 
suit our users by being more similar to most other desktop operating 
systems (well-understood and established designs, making the switch to 
using GNOME easier) and also allowing for faster app switching (so 
"power users" don't complain about GNOME as much). While I love the look 
of the vanilla GNOME 3 panel, I've taken to using this extension because 
app switching with the Activities popover (or with Alt+Tab) doesn't work 
well when there are 10+ windows.



Again, thanks for thinking about this and writing a very clear proposal.

I hope we can run with this.

-Hashem



On 04/10/2017 05:07 PM, Greg K Nicholson wrote:

Hi folks,

This is going to be a long one. Check you have a cup of tea before you dive in.


# Summary

We should improve how Gnome apps organise their menus.

We should move the contents of the panel menu into the headerbar menu,
where Preferences and Quit should be styled like in the Shell's system
menu. The panel menu should duplicate the contents of the focused
app's dash menu.

Because:
- Users expect those options to be inside the application window.
- Independent apps don't use the panel menu, which leads to an
inconsistent experience in Gnome Shell.
- Other desktop environments don't have a panel menu, so Gnome apps
have to reorganise their menus when used outside Gnome Shell.


# About me

I'm Greg K Nicholson. I've used Gnome and followed its development for
10 years. I switched to Ubuntu (6.10) from Windows XP because I wanted
Gnome. I now use Fedora for the same reason.

I live in Manchester, Great Britain. My day job is doing quality
assurance for a web development company, which involves testing for
bugs and also testing user experience design from a user's point of
view. I was part of the team that built the current iteration of
london.gov.uk, which launched in 2015.


# Intent behind the existing design

(This is from my memory of the discussions around the time of Gnome
3.0. Corrections and clarifications are welcome!)

- Users think in terms of “documents, which can be manipulated using
various applications” rather than “applications, which allow
manipulating their documents”.
- Applications commonly have multiple windows.
- Each app window represents

Re: Does GNOME Terminal need a UI update?

[Hashem Nasarat]

Welcome Justine!

Thanks for your email and the thoughtful suggestions. Although I'm not
really involved in gnome-terminal (and thus not the best respondent),
I've a couple unordered thoughts:
- I agree with everything you said.
- Specific usability criticisms are best filed as bugs.
- GNOME devs and designers haven't really yet reached consensus on how
menus should be structured. As such, choosing this topic to wade in on
is probably more complicated (politically) than it would seem (technically).
- Since app maintainers have final say in what goes, it may be quickest
to just run the ideas by the maintainer (which I believe is chpe) in IRC.
- If I recall correctly chpe likes the menubar, but is open to
incremental changes (see https://bugzilla.gnome.org/show_bug.cgi?id=672433)

Regardless, a great first step is often to build, from source, the app
you're interested in. https://wiki.gnome.org/GnomeLove/BuildGnome is a
good tutorial.

Let me know how things go!

-Hashem


On 05/28/2015 05:52 PM, Justine O'Neil wrote:
> Hey all,
> 
> I want to get my feet wet contributing to GNOME.
> 
> One thing I have noticed is that the terminal app hasn't gotten the same
> UI attention as many other GNOME apps.  I personally turn off the menu
> bar so that it looks more like the other GNOME apps.  I don't miss it
> [the menu bar], in fact it looks strange to me now whenever I see it.
> 
> Some of the functionality exposed in the menu bar is duplicated in the
> application menu.  Here is a non-exhaustive list:
> 
> * "File/Open Terminal" is exposed in the app menu as "Open new terminal"
> * "Edit/Preferences" and exposes the same preference dialog as
> "Preferences" in the app menu
> * "File/New Profile" and "Edit/Profile Preferences" are exposed under
> Profile tab in the preferences dialog 
> 
> Other functionality exposed in the menu bar might be exposed other ways.
>  For example, text size and terminal dimensions could be exposed in a
> popover menu like the icon size setting in Nautilus.
> 
> There are a few challenges inherited from the use of control sequences
> in POSIX terminals.  Ctrl-Shift-C for copy and Ctrl-Shift-V for paste
> are non-obvious variants of the standard Ctrl-C/Ctrl-V motif.  The only
> way to learn these shortcuts is through the hint in the menu bar.
> 
> Thoughts?  I would be willing to work on this.  I am good with C and I
> am learning Vala, which GNOME Terminal is written in.  I'm still
> learning GLib.  I'm not really a designer, but I know some basic
> principles and I have studied the HIG.
> 
> Cheers!
> Justine
> 
> P.S.  Since this is my first post to the list, I suppose I should give a
> little introduction. I am a 23 year-old young lady going to university
> to study science and computing.  I am getting my minor in computer
> science, but I have been programming on and off for the last decade.  I
> like to cook, and I love to argue passionately about things that matter
> to me.  And of course, I love FLOSS and GNOME!
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.15.1 unstable tarballs due (and more) (responsible: mclasen)

[Hashem Nasarat]

On 10/23/2014 08:00 PM, Release Team wrote:
> Hello all,
> 
> We would like to inform you about the following:
> * GNOME 3.15.1 unstable tarballs due
> * Feature proposals discussion heats up
> 
> 
> Tarballs are due on 2014-10-27 before 23:59 UTC for the GNOME 3.15.1
> unstable release, which will be delivered on Wednesday. Modules which
> were proposed for inclusion should try to follow the unstable schedule
> so everyone can test them.  Please make sure that your tarballs will
> be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
> will probably be too late to get in 3.15.1. If you are not able to
> make a tarball before this deadline or if you think you'll be late,
> please send a mail to the release team and we'll find someone to roll
> the tarball for you!
> 
> 
> Feature proposals discussion heats up
> 
> 
> For more information about 3.15, the full schedule, the official
> module lists and the proposed module lists, please see our colorful 3.15
> page:
>http://www.gnome.org/start/unstable

The colorful 3.15 page still links to
https://wiki.gnome.org/ThreePointThirteen
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new maintainer for gnome-dictionary?

[Hashem Nasarat]

On 10/06/2014 11:40 AM, Andre Klapper wrote:
> On Mon, 2014-10-06 at 20:57 +0530, Nirbheek Chauhan wrote:
>> I do agree that Wiktionary is probably the best source we have.
> 
> Wiktionary has a very limited API so you cannot easily use it as a
> translation dictionary, for example.

The android app QuickDic uses Wikitionary for translations:

https://code.google.com/p/quickdic-dictionary/

I haven't taken a look at how it actually does it though.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.14 Release Notes

[Hashem Nasarat]

I just tried it out and it's not obvious enough that I think a specific
description is needed:

"added ability to remove annotations by right clicking them"

On 09/11/2014 06:41 AM, Tomasz Torcz wrote:
> On Thu, Sep 11, 2014 at 11:24:20AM +0100, Allan Day wrote:
>> drago01  wrote:
>>> "evince: Remove annotations support" ... this is a bit misleading it
>>> means "option to remove annotations from a document"
>> ...
>>
>> Yeah, it became "improved annotations functionality" in the actual notes.
> 
>   "improved annotations functionality" conveys 10x less information and
> is 10x less useful than "option to remove annotations from a document".
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: SCHEDULED MAINTENANCE: 30th May, 00:00 - 01:00 CET

[Hashem Nasarat]

Did you miss a [1]?

On 05/29/2014 03:19 PM, Andrea Veri wrote:
> Hi,
> 
> we'll be performing a little maintenance this night (CET TZ) to move our
> main mount points away from NFS to the Gluster native client. This will
> help our data to failover automatically to the other configured storage
> in case of failures. [1]
> 
> The move should not affect any service but we feel having a one hour
> window for the maintenance will help us performing the move without
> rushing in case of issues during the remounts.
> 
> Thanks for your patience! 
> 
> -- 
> Cheers,
> 
> Andrea
> 
> Debian Developer,
> Fedora / EPEL packager,
> GNOME Sysadmin,
> GNOME Foundation Membership & Elections Committee Chairman
> 
> Homepage: http://www.gnome.org/~av
> 
> 
> ___
> foundation-list mailing list
> foundation-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/foundation-list
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Request for comments on security of authentication/authorisation UIs

[Hashem Nasarat]

cc'ing gnome-keyring-l...@gnome.org

On 03/26/2014 10:56 AM, Dodier-Lazaro, Steve wrote:
> Hello,
> 
> Currently on the Wayland ML, a bunch of devs are discussing security
> issues [0,1] and the need to restrict userland processes' privileges to
> e.g., take screenshots, act as virtual keyboards or read keyboard events
> for other apps, etc (basically introducing privileged interfaces that
> require explicit user authorisation). We've also been discussing how the
> introduction of Wayland allows for redesigning and securing
> authentication and authorisation UIs.
> 
> This has led me to question the way authorisation and authentication are
> currently done, and to write a couple of proposed requirements for both
> tasks. I'd be very keen on hearing the opinions of various DE developers
> on a blog post I've written [2], that focuses a lot on the
> infrastructure needs (both in Wayland and desktop environments). I'd
> also like to debate UX aspects of authorisation and authentication UIs.
> As far as I'm aware GNOME Shell implements a polkit agent and so relies
> on the polkit infrastructure for all its auth needs. Given the proposals
> I made (which really are ideas that need experimentation and
> refinement), what would fit within the GNOME way of doing things? What's
> the viewpoint of the UX people in GNOME? Can you spot any missing
> technical (security or UX) requirements in the post? Anything you
> disagree with and want me to review?
> 
> Thanks,
> 
> [0]
> http://lists.freedesktop.org/archives/wayland-devel/2014-February/013359.html
> [1]
> http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> [2] http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/
> --
> Steve Dodier-Lazaro
> PhD student in Information Security
> University College London
> Dept. of Computer Science
> Malet Place Engineering, 6.07
> Gower Street, London WC1E 6BT
> OpenPGP : 1B6B1670
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 

Great article (erm...I mean paper)!

I strongly urge you to watch Stef Walter's talk from this past summer's
GUADEC:
http://www.superlectures.com/guadec2013/more-secure-with-less-security

Stef is the author of gnome-keyring (the secure storage daemon), gcr (a
set of reusable widgets to present various security-related things), and
seahorse aka "Passwords & Keys".

For one, I believe your designs rely too heavily on standard (though
well-designed & thought-out) dialogs since, as you acknowledged, that
users often have difficulty understanding context, let alone being able
to make proper security decisions.

I believe that the solution to better security understanding lies in
innovative UI interactivity. Stef talks about this more in depth in his
talk, and you seem to allude to it:

> In an utopian world, the user knows which data can be affected by an 
> authorisation (e.g., whether their bank website currently on screen will 
> appear on a screenshot, which files’ content can be leaked to an app, etc.) 
> so s/he can make a `blink of an eye’ decision; the effects of authorisations 
> should be tangible

But as an example, if an app would like to capture screen contents
outside its borders, it would express this desire to privilege moderator
(e.g. the wayland compositor?), which would then offer controls to the
user so that they may define the area permitted to the app.

Additionally, there should probably be one more requirement added to
http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/#5-security-requirements
This being the ability for a non-privileged application to access stored
secrets (e.g. passwords stored in a password manager).
To provide another example of how to actively integrate the user into
this security-granting action, the app (say, a web browser) would issue
a call to, e.g., the compositor which would somehow present the list of
the user's saved passwords, and the user would actively have to double
click the password for the particular username/website (in addition,
perhaps the app could tell the compositor the desired username/website,
and the compositor would scroll the presented list to the suggested
password for username/website combo).

Also, you say:
> Hopefully others will agree with me and I will be able to take a FreeDesktop 
> spec out of this article

I'm unsure what kind of spec you had in mind. To me, what seems most
useful would be a standard API for a finite number of security
requirements (as in section 5 of your paper), with concrete interfaces,
AND suggested guidelines / reference implementation (gosh, that sounds
like wayland/weston...) for each of the interactive security widgets for
the requirements.

Again, thanks for the email, the article, and all this research!
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome

Re: High-DPI GNOME update: great progress, remaining issues

[Hashem Nasarat]

Thanks for the testing & the feedback. I'd recommend seeing if anything
is filed on bugzilla.gnome.org. I don't know too much to say about many
of the issues you brought up, but gnome-shell's scaling was recently
fixed in version 3.11.90
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Geoclue needs your help!

[Hashem Nasarat]

Thanks for your work!
I think you should write a blog post about this to get wider coverage.

On 01/24/2014 03:06 PM, Zeeshan Ali (Khattak) wrote:
> Hi all,
>   As some of you might have heard, last week I added a
> wifi-geolocation source to geoclue. I'm working on also adding 3G and
> GPS sources but with GNOME running on mostly laptops, most people wont
> have the needed hardware for these sources. Also is the fact that
> laptops are usually used indoor and I'm not yet sure when we will have
> GPSA support. Keeping all this in mind and that our geiop source
> typically gives us city-level accuracy, this wifi-geolocation source
> is the most important one.
> 
> The source makes use of the new Mozilla Location Service[1] and that
> being very new, does not have a lot of coverage. The good news is that
> they provide a web API and an android application to allow people to
> help them extend their coverage: Mozstumblr. I talked to our designers
> briefly about having a similar service/app in GNOME to be able to
> contribute data from GNOME itself as well but lack of GPS hardware
> makes it rather not that useful in the end.
> 
> So what I would really appreciate is for you nice folks to consider
> installing Mozstumblr on your android phones (if you have one, that
> is) and make our geolocation framework work as well as we all want it
> to.
> 
> Have a nice weekend!
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Directory bookmark feature for gnome-terminal

[Hashem Nasarat]

...why?

Perhaps https://github.com/joelthelion/autojump will be useful to you.

On 12/19/2013 12:59 PM, Quazi Marufur Rahman wrote:
> Hello all,
> 
> First apologizing, if this is not the appropriate group for my mail.
> 
> I want to implement a bookmarking feature for gnome terminal. Given a
> tag it will map the current directory with that tag.
> Next time that tag will work as like as the original directory path.
> 
> I have downloaded the source code and compiling it right now. Please
> suggest me, how to implement this.
> 
> Thanks
> Maruf 
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: App menu Help/About consistency

[Hashem Nasarat]

On 12/10/2013 11:47 AM, Sam Bull wrote:

>   There is no indication that the windows are all connected under the
> same program. Though now thinking about it, I'm struggling to pin down
> exactly what suggests to my mind that Firefox or Libreoffice windows
> belong to a single instance.
> 

A single icon in the dash/dock?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Middle click, "dumbing down" Slashdotted

[Hashem Nasarat]

On 09/24/2013 11:59 AM, tglman wrote:
> Really?? are you removing the middle-click-paste??
>
> please don't do it!! tell me what I've to patch for keep it!! I'm
> ready to rewrite all Wayland !!
>
> tnks for all the job you are doing, it's really appreciate, I can say
> GNOME 3 is so easy to use that also my grandmother can use it!!
Please don't be disparaging to grandmothers who use GNOME.
http://geekfeminism.wikia.com/wiki/So_simple,_your_mother_could_do_it
> but is becoming too easy for be used by me ;)
>
> anyway thks!
>
> Tglman
>
> On 09/24/2013 04:29 PM, Ray Morris wrote:
>> Middle click got Slashdotted. Some of the comments on Slashdot may be
>> of interest:
>> http://linux.slashdot.org/story/13/09/24/1252243/middle-click-paste-not-for-long
>>
>> It seems to me that one should be careful of any change that may, in
>> a few cases, make things simpler for users while they are new, 
>> at the expense of reducing functionality for the next 20 years, when
>> they aren't new anymore.  If wanted SIMPLE interfaces, we'd 
>> all use baby talk.  We use English to interface with each other
>> because we want a POWERFUL interface, even if we spend a lifetime 
>> discovering new ways it can be used.
>>
>>
>>
>>
>>
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: When we look for Gnome Improvements.

[Hashem Nasarat]

On 09/23/2013 11:00 AM, Leslie S Satenstein wrote:
>
> Yes, there are many small usability projects to review and
> reconsider.  For example, a  GUI tar command would be nice, and some
> other functionality that would not require me to use command line mode.
This already exists: the app is called called file-roller.

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

Re: Feature proposal: combined system status menu

[Hashem Nasarat]

On 04/22/2013 11:29 AM, Allan Day wrote:
> Part two of my reply. :)
>
> Alberto Ruiz  wrote:
> ...
>>> More details are outlined on the wiki [2]. If you do look at the
>>> designs, please pay particular attention to the example scenarios -
>>> these give a clearer idea of what the menu will actually look like.
>>> The designs aren't finalised yet, so comments and ideas are welcome.
>> My main concern while looking at the wireframes is that this would
>> change the fundamental way a lot of extensions work right now,
>> specifically I'm thinking about the MPRIS2 extension in the sound menu
>> that allows a very handy change of track or pause of your music which
>> would be a pain if done through the activities overview or the system
>> tray.
> Extension authors can still add their own menus. They could even
> relocate the volume sliders to a standalone sound menu if they wanted.
There are many great extensions which add new menus MPRIS2 [1] one, but
also the Weather [2] extension. If you concede that this proposal offers
nothing better to extension authors than what they do currently, the
benefits of consolidating menus (easy to access, simple, etc.) becomes
void for users who elect to install such extensions.

I hope soon gnome-shell extensions will become first-class citizens, and
their usage story fully flushed out, but relegating to extension-users a
sub-par experience isn't the way to go.

Extension authors are using the top menu drop-downs much as GNOME uses
the notification area pop-ups; MPRIS2 and Weather extensions are much
more functionally similar to the Rhythmbox and Removable Devices pop-ups
than they are to Accessibility, Volume, Wi-Fi, etc.

Perhaps these extensions should be transformed into ever-present or
contextually present notification-area widgets, but this doesn't work
since you lose the glance-able information with Weather, for example.
Perhaps the standard for extensions should be to merely a glanceable
icon to the proposal's combined top-menu instead of adding a separate
menu (as is the standard currently). However, this leaves the question
of where to put the remaining information still unanswered.

I'm really not sure what the answer is regarding extensions, but I hope
these issues are considered more.

-Hashem

[1] https://extensions.gnome.org/extension/55/media-player-indicator/
[2] https://extensions.gnome.org/extension/613/weather/

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

Re: loomio

[Hashem Nasarat]

I emailed the company regarding the availability of the source. They
don't have the link on the website, but the code is available.

(from r...@loomio.org)
> Loomio is on github: github.com/loomio/loomio
> 
>
> It will be great to hear how you get on with a local instance. I hope
> you can understand we have really limited resources to support local
> instances, but our docs are slowly improving to make it easier :)
>
> If it would be more convenient for you we'd be more than happy to set
> you up with an account on our hosted platform: just fill in this form:
> loomio.org/request_new_group 

I imagine it would be useful for deciding on designs/various issues that
come up. I don't know if it would be more useful to have a single group
for all of GNOME, or one for each GNOME project that's interested.

Sriram, while I agree many problems would be alleviated with more
volunteer time, I've witnessed multiple instances in the past 6 months
where decisions were not made democratically, despite a clear lack of
consensus. Most recently, there were a great deal of changes to the
gnome-shell "All Applications" view very late in the 3.8 schedule, well
after code freeze, and despite visible disagreement. Loomio seems to
offer an intuitive way of seeing how controversial a change is.

And certainly, GNOME has gotten a lot of flack from the larger Free
Software community for controversial changes.

Loomio also seems like it would be a more accessible way for more people
to get involved and provide feedback on potential decisions. Free
Software means freedom, and having a more open and democratic
decision-making process would do much to make this freedom more tangible
for more people.

On 04/14/2013 08:18 PM, Sriram Ramkrishna wrote:
> I looked at this and it seems quite interesting.  The one  problem I
> see is that this would subsume our current mailing list structure.  We
> would have to bring this in house so that people could see what the
> decisions are and why.
>
> Overall, I think it's a good way to take conversations out of IRC and
> making it formal on such a structure.
>
> But it doesn't seem like they have released the code yet.
>
> In any case, what problem are we exactly trying to solve here?  Most
> of the problems we have is related to our time schedules as
> volunteers.  This is mostly solved by adding more people to the project.
>
> sri
>
>
>
>
> On Sun, Apr 14, 2013 at 1:36 AM, ?? ?  > wrote:
>
> Hello,
>
> I found a tool for collaborative decision making and brainstorming
> called loomio:
>
> https://www.loomio.org/
>
> It's open for private beta, and I think Gnome, as a community project,
> can really benefit from using it.
>
> Currently the communication between people in the project is done in
> several channels not connected to each other: mailing list, GnomeLive
> wiki and IRC channels. All three of them treat all text as just plain
> text, meaning the computer doesn't provide us tools for specific
> content
> such as brainstorming, ideas, plans, schedules, etc.
>
> Loomio doesn't provide all of these things, but it's a great tool
> for a
> community to use for managing ideas and decisions.
>
> What do you think?
>
>
>
> Anatoly
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: Tails bounties for Seahorse

[Hashem Nasarat]

I would be interested in doing work on seahorse, I available to work on
seahorse once I graduate in May, until September.

While I have not yet contributed any code to seahorse, I've contributed
several patches to gnome-shell. Recently, I have begun exploring the
seahorse codebase to fix some bugs, and at the present I'm working on
adding an app menu.

As a new developer to seahorse, mentorship would be greatly helpful. At
this time, I cannot say for sure what the estimated workload is needed
for fixing #550736. Perhaps Stef could help in this matter.

On 04/09/2013 09:35 AM, Stef Walter wrote:
> On 09.04.2013 10:51, sajol...@pimienta.org wrote:
>> On 02/04/13 13:18, sajol...@pimienta.org wrote:
>>> Hi GNOME community,
>>>
>>> I'm part of the people developing the live system called Tails
>>> [1]. Tails has a strong focus on privacy, anonymity, encryption,
>>> etc. and of course includes GNOME and Seahorse.
>>>
>>> We are now preparing a bounties program to help upstream
>>> developers work on important bugs or interesting features for
>>> Tails. And we would like to propose a bounty opportunity for
>>> Seahorse.
>>>
>>> We are still in the process of deciding which bounties we can
>>> fund within our budget. So it is only a proposal and there is no
>>> amount of money associated to it yet. If any of you is
>>> interested, please send an email to me or ta...@boum.org and
>>> include:
>>>
>>> - A short intro to who you are and the work you've already done
>>> in Seahorse. - A estimate workload to fulfill the task. - A
>>> budget and calendar proposal.
>>>
>>> Keep in mind that your estimates should include coding, review,
>>> debugging and documentation. Stef Walter from Seahorse
>>> volunteered to support and mentor people working on this.
>>>
>>> SSH Keys in Seahorse 
>>>
>>> The import of SSH keys in Seahorse doesn't work.
>>>
>>> That's GNOME bug #550736, and still holds on Fedora 18 Live:
>>>
>>> - Importing a SSH public key returns: "Cannot display a file of
>>> this type." error message. - Importing a SSH private key returns:
>>> "No user has logged in." after being asked for the passphrase and
>>> a label.
>>>
>>> https://bugzilla.gnome.org/show_bug.cgi?id=550736
>>>
>>> As far as I understood, this is a larger scale issue related to
>>> gnome-keyring. Maybe Stef Walter can provide more information on
>>> this.
>>>
>>> We propose a bounty to fix this bug.
>> Any taker?
> I'd like to note that I'll be available to mentor developers who want
> to take on these bounties, and help work together to make sure the
> feature actually lands.
>
> If anyone has questions about what a given bounty actually involves,
> or would like me to document it further, I can do that too.
>
> Cheers,
>
> Stef
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: build.gnome.org

[Hashem Nasarat]

How do you set that up? Do you somehow install the tarballs into the
jhbuild install directory?
On Feb 6, 2013 9:35 PM, "Alberto Ruiz"  wrote:

> If you use the last point release moduleset[0] from tarballs I find
> the experience faster and less error prone.
>
> Then I configure the module I want to hack on to build from master and
> this usually works, in some weird cases, master requires master from
> another dependency, but this is very rare and addressable case.
>
> [0] ftp://ftp.gnome.org/pub/gnome/teams/releng/3.7.4/
>
> 2013/2/7 Sriram Ramkrishna :
> > I'm not sure how I missed this thread..
> >
> > Regarding maintaining jhbuild  up to gtk+ - I would actually like to see
> > this up to at gnome-shell.  We have a number of people who I have
> convinced
> > to help volunteer to resolve bugs for GNOME 3.7, but are very frustrated
> > with getting jhbuild to build for them.
> >
> > We really should make it a goal to get an SDK for our volunteers to help
> fix
> > issues.
> >
> > We are considering doing a jhbuild hackfest once a month for volunteers
> to
> > learn and understand how to build under jhbuild and grow enough builders
> to
> > make it self sustaining.
> >
> > But getting a certain set of modules always in buildable state is a great
> > goal and I hope we can do this.
> >
> > sri
> >
> >
> > On Fri, Jan 18, 2013 at 12:39 AM, Jean-Baptiste Lallement
> >  wrote:
> >>
> >> On 01/16/2013 07:39 AM, Martin Pitt wrote:
> >>>
> >>> Hello Colin,
> >>>
> >> Hi Martin, Colin,
> >>
> >>
> >>> Colin Walters [2013-01-15 15:34 -0500]:
> 
>  >On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
>  >
> >
> > > >We have experimented with that a bit, by building
> > > >
> > > >
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
> 
>  >
>  >Interesting!  Looks quite useful.  Are you doing anything with
>  >respect to the "jhbuild sysdeps --install" infrastructure or is
>  >the system package set maintained manually?
> >>>
> >>> Right now in our Juju charm it's a manual list:
> >>>
> >>>
> >>>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
> >>>
> >>> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not work
> >>> well enough in principle?
> >>>
> >> In Quantal, there was missing dependencies, so I went the straightest
> way
> >> and installed them directly. Now that I have a better understanding how
> >> jhbuild works that's something I want to reconsider for Raring and avoid
> >> maintaining them in 2 different places.
> >>
> >> --
> >> Jean-Baptiste
> >> IRC: jibel
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> Cheers,
> Alberto Ruiz
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: build.gnome.org

[Hashem Nasarat]

Is one (jhbuild vs ostree) preferable going forward when there is an SDK
and developer story?
On Dec 30, 2012 1:09 PM, "Giovanni Campagna" 
wrote:

> 2012/12/30 Jasper St. Pierre :
> > Can we just redirect build.gnome.org to ostree.gnome.org ?
> >
> > Having it build apps or something like that on top of its root tree as a
> > separate build process would be nice.
>
> FWIW, I'm currently testing building core apps with ostree, as well as
> fixing ostree enough to be dogfoodable for me. I'll report back when I
> have it finished, but so far it seems to work.
> However, there is still a value in keeping jhbuild running, as
> application development with jhbuild is a lot faster than
> ostree/ostbuild, in particular given the "setup costs" of building the
> entirety of gnomeos just to get running. This until we have an SDK and
> application story...
>
> Giovanni
>
> >
> > On Sun, Dec 30, 2012 at 12:12 PM, Cosimo Cecchi 
> wrote:
> >>
> >> Maintaining the Debian jhbuild server running was quite a bit of manual
> >> work for no clear benefit, so I turned it off at some point this fall.
> >> If it's still useful for people, I can try to revive it but IMO Colin's
> >> build server in #testable is a much better solution (even if it's not
> based
> >> on jhbuild). Maybe we should try to have it also build another wider
> >> gnome-apps-like moduleset?
> >>
> >> Cosimo
> >>
> >>
> >> On Sun, Dec 30, 2012 at 5:50 PM, Andre Klapper  wrote:
> >>>
> >>> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to
> be
> >>> offline, and the Debian one has not been updated since October.
> >>>
> >>> Does anybody feel responsible for this?
> >>>
> >>> andre
> >>> --
> >>> Andre Klapper  |  ak...@gmx.net
> >>> http://blogs.gnome.org/aklapper/
> >>>
> >>> ___
> >>> desktop-devel-list mailing list
> >>> desktop-devel-list@gnome.org
> >>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >>
> >>
> >>
> >> ___
> >> desktop-devel-list mailing list
> >> desktop-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> >
> >
> >
> >
> > --
> >   Jasper
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: jhbuild

[Hashem Nasarat]

1. You could just install the updated deb file:
http://packages.debian.org/sid/libicu-dev#pdownload
2. Also if you have trouble with finding .pc files for packages that you
believe you had installed, make sure that your PKG_CONFIG_PATH variable is
set properly.

(In debian I had to put the following in my jhbuildrc:)
addpath('PKG_CONFIG_PATH', '/usr/lib/x86_64-linux-gnu/pkgconfig')
addpath('PKG_CONFIG_PATH', '/usr/lib/pkgconfig')


On Mon, Dec 24, 2012 at 12:21 PM, Lanoxx  wrote:

> Both packages are installed, as I wrote, there is a bug in libicu-dev
> 4.1.1 where the pkg-config files are not available, this bug is only fixed
> in 4.1.1-10 which is not going to be backported to Ubuntu 12.10 which
> currently has 4.1.1-8 (which still has this bug). As for wireless tools, it
> is also installed, but I guess for some reason is does not supply this
> header file:
>
>
> No native package found for wireless-tools (/usr/include/wireless.h)
>
> So the interesting question is, how do I get the required .pc files for
> all for these packages if my distribution (ubuntu) does not supply them in
> their packges?
>
> Regards
> Lanoxx
>
>
> On 24/12/12 15:00, Emily Gonyer wrote:
>
>> try sudo apt-get install wireless-tools libicu-dev - they are in
>> ubuntu's repos and should be a new enough version.
>>
>> On Mon, Dec 24, 2012 at 8:29 AM, Lanoxx  wrote:
>>
>>> Hi,
>>>
>>> I have already run jhbuild sysdeps --install, and also ran jhbuild build
>>> anjuta, with the first one I get this output:
>>>
>>> I: Using apt-file to search for providers; this may be slow.  Please
>>> wait.
>>> I: No native package found for alsa (/alsa.pc)
>>> I: No native package found for libv4l (/libv4l2.pc)
>>> I: No native package found for gl (/gl.pc)
>>> I: No native package found for libicu (/icu-i18n.pc)
>>> I: No native package found for soundtouch (/soundtouch-1.4.pc)
>>> I: No native package found for gmime (/gmime-2.6.pc)
>>> I: No native package found for exiv2 (/exiv2.pc)
>>> I: No native package found for taglib (/taglib.pc)
>>> I: No native package found for wavpack (/wavpack.pc)
>>> I: No native package found for libusb1 (/libusb-1.0.pc)
>>> I: No native package found for libatasmart (/libatasmart.pc)
>>> I: No native package found for xcb-dri2 (/xcb-dri2.pc)
>>> I: No native package found for libvpx (/vpx.pc)
>>> I: No native package found for libzeitgeist (/zeitgeist-1.0.pc)
>>> I: No native package found for libarchive (/libarchive.pc)
>>> I: No native package found for cairomm (/cairomm-1.0.pc)
>>> I: No native package found for exempi (/exempi-2.0.pc)
>>> I: No native package found for libmusicbrainz (/libmusicbrainz5.pc)
>>> I: No native package found for libgphoto2 (/libgphoto2.pc)
>>> I: No native package found for texinfo (/usr/bin/makeinfo)
>>> I: No native package found for wireless-tools (/usr/include/wireless.h)
>>> I: No native package found for gdbm (/usr/include/gdbm.h)
>>> I: No native package found for libdb (/usr/include/db.h)
>>> I: No native package found for cracklib (/usr/include/crack.h)
>>> I: No native package found for mpfr (/usr/include/mpfr.h)
>>> I: Nothing to install
>>>
>>> and with the second one I get this output:
>>>
>>>
>>> Required packages:
>>>System installed packages which are too old:
>>>  (none)
>>>No matching system package installed:
>>>  wireless-tools (required=25)
>>>  libicu (icu-i18n.pc, required=4)
>>> jhbuild build: Required system dependencies not installed. Install using
>>> the
>>> command 'jhbuild sysdeps --install' or to ignore system dependencies use
>>> command-line option --nodeps
>>>
>>> The problem seems to be, that my system does not have the required
>>> packages
>>> (or rather they are there but the version is too low). So I am hoping
>>> that I
>>> can install the required dependencies (especially libicu and
>>> wireless-tools)
>>> with jhbuild somehow? The problem with libicu is for example that Ubuntu
>>> ships the version 4.1.1-8 but I need 4.1.1-10 otherwise the .pc files are
>>> missing).
>>>
>>> Kind Regards and merry christmas
>>> Lanoxx
>>>
>>>
>>> On 24/12/12 12:52, Sébastien Wilmet wrote:
>>>
 Hello,

 On Sun, Dec 23, 2012 at 09:53:36PM +0100, Lanoxx wrote:

> I am using jhbuild and trying to compile anjuta (with anjuta-extras)
> to test a patch that was applied recently on anjuta-extras.
>
> jhbuild build
>
 The gnome-love list would have been a better place, but anyway, you must
 mention the module you want to build:

 $ jhbuild list anjuta
 $ jhbuild build anjuta

 Or add it in your ~/.jhbuildrc.

 Best regards,
 Sébastien

>>>
>>> __**_
>>> desktop-devel-list mailing list
>>> desktop-devel-list@gnome.org
>>> https://mail.gnome.org/**mailman/listinfo/desktop-**devel-list
>>>
>>
>>
>>
> __**_
> desktop-devel-lis