1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.GTK.GN

  • Debian and the GNOME advisory board meeting

    From Chris Lamb@21:1/5 to All on Mon Jul 2 18:20:01 2018
    Hi Gnome/GTK developers,

    Apologies for not sending this out sooner. As you know, Debian has a
    seat on the Gnome Advisory Board which is due to meet soon. Not much is officially-officially expected of Debian in this capacity, but I would obviously like to raise any longer-term, roadmap or philosophy-oriented
    issues in order to help you folks.

    Previous issues that have been raised include getting some downstream
    branding guidelines as well as syncing schedules as best as possible to
    fit the distributions that have an "LTS" or release schedule that is
    roughly equivalent at least in terms of the time between releases, ie.
    Debian.

    (Specific and/or entirely-technical issues on the upstream bug tracker naturally would not be entirely appropriate unless you think I could
    help unblock them, of course.)

    So, yes, one provocative way of phrasing it might be... what sucks for
    you or our users about being downstream from Gnome or GTK right now?
    What is good..?

    Thank you very much for your input.


    Best wishes,

    --
    ,''`.
    : :' : Chris Lamb
    `. `'` lamby@debian.org / chris-lamb.co.uk
    `-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Lamb@21:1/5 to All on Tue Jul 3 13:10:01 2018
    Hi Jonathan,

    It would be great if there was better support for locally installed
    packages, at least being able to disable extensions.gnome.org updates
    for system-wide installed extensions would be good start. It would at
    least put users at lower risk of breakage and malicious updates.

    This latter point is certainly worth raising! Also seems somewhat
    related to the installation of unmalicious-but-non-free software from
    such sites.

    I've been meaning to file a bug for this, and I'm not sure weather it's really an on-topic issue for the board

    Please do file a bug (or bugs).


    Regards,

    --
    ,''`.
    : :' : Chris Lamb
    `. `'` lamby@debian.org / chris-lamb.co.uk
    `-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Carter (highvoltage)@21:1/5 to Chris Lamb on Tue Jul 3 12:50:01 2018
    Hi Chris

    On 02/07/2018 18:10, Chris Lamb wrote:
    (Specific and/or entirely-technical issues on the upstream bug tracker naturally would not be entirely appropriate unless you think I could
    help unblock them, of course.)

    So, yes, one provocative way of phrasing it might be... what sucks for
    you or our users about being downstream from Gnome or GTK right now?
    What is good..?

    Thank you very much for your input.

    I've been meaning to file a bug for this, and I'm not sure weather it's
    really an on-topic issue for the board, but it is squarely in the
    category of something that really sucks badly on Gnome right now, and
    that's how extensions to updates work, which is actually a big problem
    in Debian.

    A quick bit of background. If a user installs an extension from the https://extensions.gnome.org website, it is installed under ~/.local/share/gnome-shell/extensions, when an updated extension from
    the site is available, a notification is popped up prompting the user to upgrade the package. So far, so good!

    An administrator can also install a system-wide extension under /usr/share/local/gnome-shell/extensions. Extensions installed here are available system-wide for all users who wish to enable them. This is
    also where we install extensions from Debian packages.

    The problem is, when an extension is installed locally by a local
    administrator or by a package, the user will still be prompted to
    upgrade from the extensions website when a newer version is available
    from there, which leads to a bunch of problems, firstly that a user can
    be upgraded to a newer package with new bugs or that just isn't that
    well supported on stable anymore. Also, in a corporate environment I
    might have custom extensions installed that will then be upgraded to
    versions from the shell-extensions site.

    It would be great if there was better support for locally installed
    packages, at least being able to disable extensions.gnome.org updates
    for system-wide installed extensions would be good start. It would at
    least put users at lower risk of breakage and malicious updates.

    -Jonathan

    --
    ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) <jcc>
    ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage
    ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org
    ⠈⠳⣄⠀⠀⠀⠀ Be Bold. Be brave. Debian has got your back.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Didier Roche@21:1/5 to All on Tue Jul 3 15:30:02 2018
    Le 03/07/2018 à 12:51, Chris Lamb a écrit :
    Hi Jonathan,

    It would be great if there was better support for locally installed
    packages, at least being able to disable extensions.gnome.org updates
    for system-wide installed extensions would be good start. It would at
    least put users at lower risk of breakage and malicious updates.
    This latter point is certainly worth raising! Also seems somewhat
    related to the installation of unmalicious-but-non-free software from
    such sites.

    I've been meaning to file a bug for this, and I'm not sure weather it's
    really an on-topic issue for the board
    Please do file a bug (or bugs).

    Hey Chris,

    We'll see each other at the adboard, but I'll be on the board's side
    (for the last time, it seems ;)). Note that I restrained on purpose the
    first discussions about extensions being part of a mod, but this can be extended (see discussions and hints I gave)  to any system extensions.
    For your information, it's a challenge the we face at ubuntu as well
    since we switched to GNOME Shell.

    I have tried to raise this on the mailing list in October: https://mail.gnome.org/archives/gnome-shell-list/2017-October/msg00034.html After waiting and not hearing, I've go on and filed a bugzilla report
    with patches: https://bugzilla.gnome.org/show_bug.cgi?id=789852

    I tried weekly pings on this issue, not getting a lot of tractions
    upstream. I finally got some answers on https://bugzilla.gnome.org/show_bug.cgi?id=789852#c14.
    After trying (see following comments) many times to get an answer on my followup, I did implement the set of patch on the "agreed" part (note
    that there is several side effects of this discussions, like extensions
    being part of a mod appearing as disabled).

    Once GNOME Shell moved to gitlab, I rebased and opened the first GNOME
    Shell MR: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/1
    As you can see, despite pings on IRC, on gitlab and requests, it doesn't
    seem to interest upstream, even if RHEL is using GNOME Classic and thus,
    is impacted by it.

    At the last resort, for our 18.04 LTS, I implemented a minimal distro
    patch (), but I'm not fully satified as the finale solution is way
    better (but really intrusive, so doesn't qualify as a maintainable distro-patch). https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gnome-shell/tree/debian/patches/ubuntu_block_mode_extension_update.patch?id=65d8e54e48028903b626117d6f19a4aab42353fa

    I would love someone not on the GNOME board to raise this again. We have patches, it's a slight adaptation, and I think such issues from a distro maintainance perspective (in particular in the corporation or support
    mode) needs to be raised.

    Thanks,
    Didier

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Lamb@21:1/5 to All on Wed Jul 4 11:10:02 2018
    Dear Didier,

    I would love someone not on the GNOME board to raise this again.

    I will definiteley raise this. Thank you.


    Regards,

    --
    ,''`.
    : :' : Chris Lamb
    `. `'` lamby@debian.org / chris-lamb.co.uk
    `-

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)