Re: GitLab CI runners for non-Linux systems

[Arun Raghavan]

On 18 May 2018 at 18:51,   wrote:
> On Fri, May 18, 2018 at 5:52 AM Philip Withnall 
> wrote:
>>
>> Can anybody else provide and maintain CI runners for other platforms?
>> I’d particularly like to see:
>>  • *BSD (probably OpenBSD and NetBSD)
>>  • macOS (ideally several versions, since we support from OS X 10.7
>> upwards[2])
>>  • Android (probably a cross-build)
>>  • More Windows configurations (currently we have MSYS2 on Windows
>> Server 2012; ideally we’d have a MinGW-w64 runner too)
>
>
> I can help write the CI job configurations for macOS, but I don't know how
> to host or set up a runner.
>
> (For a shortcut solution, we could consider farming out the macOS builds to
> Travis CI, which has macOS runners already available)

If anyone can point me to how to set up an Android runner I could try
to pitch in there.

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

Re: Desktop miniconf @ Linux Plumbers Conference

[Arun Raghavan]

On 10 May 2018 at 03:47, Christian Hergert  wrote:
>
> On 05/09/2018 02:59 PM, Sriram Ramkrishna wrote:
> > So If there is sufficient interest, I will volunteer my time to run the
> > miniconf this year.  Those of you who have items worth discussing can
> > think of talks we can present to a diversified audience.
>
> Some avenues of discussion/talks that come to mind, that vary in terms
> of how much kernel-space they involve.
>
>  - Audio
>- Real-time/low-latency (pipewire/jack/gstreamer/etc)
>- Sandboxing audio APIs (pipewire/pulse)
>  - Video
>- Difficulties and challenges in ensuring hardware decoding
>- Ensuring frame-synchronization for applications (wayland
>  presentation protocol, etc).
>  - Firewalling/restricted network to sandboxed applications
>  - Securing devices from malicious peripherals (USB, t-bolt, etc)
>  - How to take advantage of new file-system features in applications
>(xfs/btrfs reflink)
>  - Graphics
>- Profiling graphics performance in compositors and toolkits
>  (GL/Vulkan/drm/etc)
>- Virtualized GPU for sandboxes/VMs?
>  - Scheduler performance related to desktop workloads
>  - Debugging battery/acpi/suspend/etc
>  - IPC/messaging (kdbus/bus1/varlink/dbus/binder)
>  - A11y/Input Methods in early boot (full-disk encryption on a tablet?)
>  - Sandboxed device access (device-tree, capabilities-based access)

I'm happy to see a renewed focus on the plumbing aspects. I could try
to make it this year, especially if there are topics around
audio/video to discuss and work on.

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

Re: Too many broken modules

[Arun Raghavan]

On 31 July 2017 at 12:11,   wrote:
> Hi devs,
>
> There are too many broken modules right now! Here is the list of modules
> that Javier had to skip when releasing 3.25.4:
>
> 'pango', 'at-spi2-atk', 'vte', 'gdm', 'clutter-gtk', 'graphene', 'nautilus',
> 'glade', 'libgxps', 'libgepub', 'gnome-font-viewer', 'fwupd',
> 'gnome-terminal', 'totem', 'simple-scan', 'usbredir', 'spice-gtk',
> 'gst-plugins-base', 'gst-plugins-bad', 'gnome-dictionary',
> 'nautilus-sendto', 'gnome-builder', 'gnome-chess', 'gnome-sudoku'
>
> That's wy too many broken modules. We normally have just one or two
> broken modules per release. Please, if your module is in the list above,
> make sure your module builds in JHBuild using your latest *tarball* release.
> In particular, if JHBuild is configured to build your module using meson,
> and you still have an Autotools build, you *must* ensure every meson.build
> is distributed, otherwise the build cannot work.
>
> I'll be contacting individual maintainers regarding build breakage next
> week. It'd be easier if everything is fixed by Monday next week. :) I'm
> hoping to release 3.25.90 on time next week, but will delay as long as
> required if modules are not building.

Is there some place we can look at logs of the current build? I don't
have a jhbuild-y setup here, but I'd be happy to look at the gst-*
failures.

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

Re: Proposal to deploy GitLab on gnome.org

[Arun Raghavan]

On 17 May 2017 at 13:56, Carlos Soriano  wrote:
> Hey Arun,
>
> Glad to hear you are positive about the proposal!
>
>  Let me answer your points:
>
>  Original Message 
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 7:32 AM
> UTC Time: May 17, 2017 5:32 AM
> From: a...@accosted.net
> To: Carlos Soriano 
> desktop-devel-list@gnome.org 
>
> On 17 May 2017 at 03:57, Carlos Soriano via desktop-devel-list
>  wrote:
>> Hello Mattias,
>>
>> Thanks for sharing your thoughs!
>>
>> Your concern is about using fast forward merge. Yes, we raised this
>> concern
>> as the top most important for us, and as we mention in the wiki we have
>> good
>> news, GitLab team is willing to strongly consider making fast forward
>> merge
>> to CE if GNOME decides to switch to GitLab.
>>
>> Don't worry much about this one :)
>
> Thank you for taking this up. While I share some concerns voiced on
> this thread, overall, I think it is a good thing for us to be trying
> to move to tools that make our lives easier as well as lower the bar
> for new contributors who are used to the Github-esque workflow.
>
> My first note to folks who are concerned about GitLab being an evil
> semi-closed project would be to look at the repository at
> https://gitlab.com/gitlab-org/gitlab-ce -- having shared these
> concerns in the past, I feel a lot more positive looking at degree to
> which external contributions are encouraged.
>
>
> Yes, as mentioned in a different thread, more than 50% is by community.
> Of course we had the same concerns in the past But then we explored the tool
> and the team more, realized that in the CE repo there ara quite a lot of
> non-gitlab contributions, read more about them and their actions in the past
> (like moving EE features to CE based on user input), and talked with them.
> Now we are pretty confident about it.
>
>
> The things I worry about are the features that are in the EE and not
> in CE that I think will be important for us either now, or down the
> line:
>
> * Git hooks -- either admins with file system access need to manage
> these for projects because the web interface to do this is EE-only
>
>
> This is not a problem really. We were doing it already with Bugzilla/cgit.
>
>
> * Automatic rebase for fast forward commits -- Carlos mentioned that
> this might be something that'll just be part of the CE
>
>
> Yes, no worries about this one.
>
>
> * Single-sign-on with the remaining GNOME account infra -- maybe this
> will just be something we'll have to maintain ourselves
>
>
> Care to expand? You mean using the gnome account to login? If so, that's
> already possible.

I looked at the LDAP support item in the CE vs. EE page, but if it's
solved already, that's awesome.

> * Issue templates -- again, this seems like a basic feature for this
> kind of platform so we can get more meaningful bug reports to start
> with
>
>
> This is on CE.
> https://docs.gitlab.com/ce/user/project/description_templates.html
> You might remembered from the past, before 8.1, when it was EE.
> Test our gitlab test instance as outlined in the wiki so you know what's the
> current status of the tool, since it changed and added quite a few things in
> the last months that otherwise we would have ponder much more if it makes
> sense for us.

I was looking at the CE vs. EE page -- I guess that needs to be updated.

> * Multiple issue boards per project -- I haven't used the issue
> boards yet, but this seemed like a rather artificial limitation rather
> than an actual feature differentiated in EE
>
>
> Not sure how this is necessary for us, compared to what we have in Bugzilla.
> Of course this would be useful, but the frame of the problem is more about
> what we have now vs what we could have.
>
>
> Other than the hooks which might be an immediate concern, I guess the
> rest of these aren't a step down from where we are, so if we have an
> idea of how to deal with these in the future, that's good enough.
>
>
> Template issues and ff merge would have been a step down. Not sure template
> issues would have been extremely important, but still. But as mentioned,
> template issues in is CE since a few months ago, and fast forward merge
> shouldn't worry you :)

Well, that's two more thumbs up from me, then. :-)

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

HiDPI and fractional scaling

[Arun Raghavan]

Hello,
I'm typing this from my Sony Vaio Pro 13. The resolution on this thing
is 1920x1080 on a 13 display, putting it at about 160 dpi, so I don't
get any automatic scaling love.

Without scaling, there is a massive amount of eye strain, and it
really isn't comfortable to use. I can increase text-scaling to 1.1 as
a less-than-perfect workaround, and things are better, but then I plug
in a monitor and everything is too huge on the monitor.

Is there a plan to address this? I can't imagine that this is uncommon
-- a number of laptops in my shortlist before I bought this one were at
about the same size and resolution. I'm happy to help, since this
hobbles my shiny new laptop quite badly.

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

Re: BlueZ 5 migration

[Arun Raghavan]

On Mon, 2013-07-01 at 17:44 +0200, Bastien Nocera wrote:
 On Tue, 2013-07-02 at 01:35 +1000, Andrew Cowie wrote:
  On Mon, 2013-07-01 at 09:47 +0200, Bastien Nocera wrote:
   I'd rather ship without Bluetooth audio support in 3.10.0 
  
  You're kidding, right?
 
 No. It's PulseAudio's remit, not GNOME's. And until the day we're
 shipping an actual product, that's the way it's going to fly.

I _really_ don't think it makes any sense to go down the finger-pointing
route, so please refrain from doing this.

-- Arun

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

Re: BlueZ 5 migration

[Arun Raghavan]

On Mon, 2013-07-01 at 09:47 +0200, Bastien Nocera wrote:
 On Fri, 2013-06-28 at 17:46 +0530, Arun Raghavan wrote:
[...]
  I think it makes sense to use this approach with 3.10 as well - support
  BlueZ 4 and 5 as a compile-time option for this release, get some more
  user-testing during this cycle from the more adventurous, and then
  switch to BlueZ 5 only in 3.12
 
 Given that we had to break the API to support Bluez5, I really don't
 want to be supporting 2 versions of BlueZ in gnome-bluetooth and
 associated modules. Waiting another 6 months would mean that we'd rely
 on the unsupported BlueZ 4 code for a total of a year and a half.
 
 I'd rather ship without Bluetooth audio support in 3.10.0 and have the
 support come in in an subsequent point update. This is definitely better
 than relying on unsupported versions of BlueZ.

BlueZ 4 is no longer supported is only a tenable argument if it didn't
drop functionality. Put another way, from users' perspective, BlueZ 4
vs. 5 doesn't matter. Having something that worked fine go away, for no
visible gain, does.

I'm not even saying we should be providing active support for BlueZ 4
installs - just that we deal with messiness of retaining 4.x support in
code for one cycle.

Cheers,
Arun

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

Re: BlueZ 5 migration

[Arun Raghavan]

Looping in Luiz Augusto von Dentz from the BlueZ side since he might
want to pitch in as well.

Cheers,
Arun

On Mon, 2013-07-01 at 15:02 +0530, Arun Raghavan wrote:
 On Mon, 2013-07-01 at 09:47 +0200, Bastien Nocera wrote:
  On Fri, 2013-06-28 at 17:46 +0530, Arun Raghavan wrote:
 [...]
   I think it makes sense to use this approach with 3.10 as well - support
   BlueZ 4 and 5 as a compile-time option for this release, get some more
   user-testing during this cycle from the more adventurous, and then
   switch to BlueZ 5 only in 3.12
  
  Given that we had to break the API to support Bluez5, I really don't
  want to be supporting 2 versions of BlueZ in gnome-bluetooth and
  associated modules. Waiting another 6 months would mean that we'd rely
  on the unsupported BlueZ 4 code for a total of a year and a half.
  
  I'd rather ship without Bluetooth audio support in 3.10.0 and have the
  support come in in an subsequent point update. This is definitely better
  than relying on unsupported versions of BlueZ.
 
 BlueZ 4 is no longer supported is only a tenable argument if it didn't
 drop functionality. Put another way, from users' perspective, BlueZ 4
 vs. 5 doesn't matter. Having something that worked fine go away, for no
 visible gain, does.
 
 I'm not even saying we should be providing active support for BlueZ 4
 installs - just that we deal with messiness of retaining 4.x support in
 code for one cycle.
 
 Cheers,
 Arun

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

Re: BlueZ 5 migration

[Arun Raghavan]

On Thu, 2013-06-27 at 15:41 +0100, Javier Jardón wrote:
 On 27 June 2013 14:09, Arun Raghavan arun.ragha...@collabora.co.uk wrote:
 
  I had brought this up on IRC, but that morphed into a discussion with
  the BlueZ folks, so let me just summarise here:
 
  * The latest released PulseAudio does not support BlueZ 5, only BlueZ 4
 
  The BlueZ folks (João Paulo and Mikel) have been doing the heavy-lifting
  on this front. Knowing what the timelines are from GNOME's perspective
  would be useful in figuring out when we need to get this in by (and
  released) and whether this is possible at all.
 
 Hi Arun,
 
 thanks for the heads up
 You can check the release schelude here: [1]

Thanks.

 As you can see TheFreeze of all the modules is August 19, so ideally
 the new pulseaudio version should be ready some time before.

This depends on the code going into BlueZ first, then into PA, and both
making releases (there are currently a whole lot of changes in master,
so we'd probably need to do a couple of rounds of RCs before shipping a
new stable release).

 A question about BlueZ: Is version 4 parallel installable with version 5?

As Bastien pointed out, they will not be. To make the transition less
painful, our plan on the PulseAudio side is to support both BlueZ 4 and
5 in the short term till there are enough users have migrated to BlueZ 5
and we can feel more confident about dropping BlueZ 4 support.
Fortunately, we are able to separate this out without much in the way of
additional maintenance burden.

I think it makes sense to use this approach with 3.10 as well - support
BlueZ 4 and 5 as a compile-time option for this release, get some more
user-testing during this cycle from the more adventurous, and then
switch to BlueZ 5 only in 3.12

Cheers,
Arun

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

Re: BlueZ 5 migration

[Arun Raghavan]

On Fri, 2013-06-14 at 11:42 +0200, Bastien Nocera wrote:
 Heya,
 
 gnome-bluetooth[1] and gnome-shell[2] have been ported to use BlueZ 5,
 the new major version of the Bluetooth handling daemon and utilities[3],
 and will available in GNOME 3.10.
 
 gnome-user-share is still being worked on [4] as it requires some
 obexd/bluetoothd changes. NetworkManager port is also in progress.
 PulseAudio already supports both BlueZ 4 and Bluez 5.

I had brought this up on IRC, but that morphed into a discussion with
the BlueZ folks, so let me just summarise here:

* The latest released PulseAudio does not support BlueZ 5, only BlueZ 4

* Initial support for BlueZ 5 has been merged in master, but this is
only A2DP and not HSP/HFP (in non-Bluetooth-speak, that means you can
play music but not use it for voice calls)

* Based on some discussion, the consensus was for HSP support to be
implemented BlueZ first, following which we'll need to add support for
this in PulseAudio

All this means is that it is not clear at this point whether we'll have
a release of PulseAudio which supports BlueZ 5, and whether there will
be a BlueZ 5.x version with voice calls support in time for GNOME 3.10.

The BlueZ folks (João Paulo and Mikel) have been doing the heavy-lifting
on this front. Knowing what the timelines are from GNOME's perspective
would be useful in figuring out when we need to get this in by (and
released) and whether this is possible at all.

Cheers,
Arun

___
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

[Arun Raghavan]

On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
 Hi all,
 
 This is something that me, Jon and Jakub have been thinking about for
 some time, and is now at the stage where we can start to think about
 implementation. I'm proposing it as a feature for 3.10 [1].
 
 The main element of the design is to combine the sound, network,
 bluetooth, power and user menus into a single menu. This will enable

Just as a note, this does remove one feature I kind of like, which is
the ability to change the volume by scrolling on the volume icon. I know
it's minor, but I've found it useful.

On the other hand, I tend to use the Advanced Volume Mixer extension[1],
anyway. I don't know if it's just me, but I think some of that stuff
could be useful in the default sound menu as well (such as per-stream
volume/mute control).

Cheers,
Arun

[1] https://extensions.gnome.org/extension/212/advanced-volume-mixer/

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

Re: Git: Do not use http to access Git!

[Arun Raghavan]

On Thu, 2011-02-17 at 14:04 +0100, Olav Vitters wrote:
[...]
  If this is the case, git being awesome as it is, perhaps someone could
  set up a remote that offers http cloning that updates once a day or so.
  This would let people clone a repo, and still submit their work via
  format-patch etc.
 
 I've noticed the following after sending the initial mail:
 http://progit.org/2010/03/04/smart-http.html
 http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
 
 Basically: If the client has git 1.6.6+, there is a possibility to be as
 (almost as?) efficient as the git protocol using http. I've reconfigured
 all git repos to have:
   http.getanyfile false
   http.receivepack false
 Meaning: Only want efficient Git.
 
 My intend is to allow the git 1.6.6+ method, and explicitly disallow the
 previous method.
 
 This requires some sysadmin work to setup (newer git, newer cgit, etc).
 Doing that atm, not sure when I'll finish.

Thanks! A number of colleges here in India block access to all ports and
allow HTTP over a proxy, so that's a whole bunch of people who will
benefit from this.

Cheers,
Arun

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

Re: Minimum system requirements for GNOME Shell

[Arun Raghavan]

On Fri, 2010-12-24 at 23:30 +, Emmanuele Bassi wrote:
[...]
 if you want comparisons, you should be looking at how compiz and kwin
 perform on the same architecture, and see if mutter/gnome-shell are
 lagging behind. there is no reason why they should, and we recently
 tested mutter with its default clutter-based compositor plugin and
 verified that it beats (or performs as well as) compiz on the same
 machine with intel GPU.

In the context of Nirbheek's post, that comparison is meaningless. The
point is to figure out the impact on the the rather large number of
people going from a setup where 3D perf was a non-issue to one where it
suddenly is.

Which is why it makes sense, as we're getting close to a GNOME 3
release, to draw the line /somewhere/ saying if you have at least this
kind of hardware, you will have a smooth experience with GNOME 3 / GNOME
Shell. Summarising your post an Johannes', we could probably document
this as:


Any Intel integrated graphics card ≥ i915/945 or ATI/NVidia GPU from a
similar period. With NVidia chips, you will need to use NVidia's
proprietary drivers. fill in information about ATI here.


Cheers,
Arun

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

Re: external dependency review for 2.91

[Arun Raghavan]

On Thu, 2010-09-30 at 22:44 -0400, Matthias Clasen wrote:
 Hi, I looked over the external dependencies for 2.91 [1]. I've bumped
 the recommended versions to current versions in many places. There are
 some places where we need to bump mnimal versions:

Could we bump the recommended version of gupnp-dlna to 0.4.0 (which is
the current stable release)?

Cheers,
Arun

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

Re: external dependency review for 2.91

[Arun Raghavan]

(sorry about the dupe, didn't see the CC-list)

On Fri, 2010-10-01 at 13:15 -0400, Matthias Clasen wrote:
 On Fri, Oct 1, 2010 at 12:18 PM, Arun Raghavan
 arun.ragha...@collabora.co.uk wrote:
  On Thu, 2010-09-30 at 22:44 -0400, Matthias Clasen wrote:
  Hi, I looked over the external dependencies for 2.91 [1]. I've bumped
  the recommended versions to current versions in many places. There are
  some places where we need to bump mnimal versions:
 
  Could we bump the recommended version of gupnp-dlna to 0.4.0 (which is
  the current stable release)?
 
 
 Done. 0.3 still works ?

Thanks! Yes it does work, but 0.4 works better.

Cheers,
Arun

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

Re: Bumping gupnp-dlna requirement

[Arun Raghavan]

Hello folks,

On Thu, 2010-08-12 at 15:57 +0300, Zeeshan Ali (Khattak) wrote:
 Hi everyone,
To whom it may concern (anyone? :)), next release of rygel will
 require the upcoming release of gupnp-dlna (due for release tomorrow)
 .. We're trying to put all API/ABI changes in already so after this
 we'll only need to change the recommended version, though we can't
 guarantee that. That said, API/ABI of gupnp* (including gupnp-dlna) is
 guaranteed to be frozen in 2 weeks.

Quick addendum: For those who are interested, gupnp-dlna 0.3.0 has been
released: http://lists.o-hand.com/gupnp/0984.html

Regards,
Arun

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