1. 21 May, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Add content_rating to AppData files · 0a136095
      Stephan Bergmann yazdı
      At least building on Flathub makes presence of this information a hard
      requirement now (see <https://blogs.gnome.org/hughsie/2019/03/28/
      new-appstream-validation-requirements/> and witness the failed
      The suggested way to calculate that information is via the form at
      <https://hughsie.github.io/oars/generate.html>, which I filled in as follows
      (the answers I selected are prefixed with "=>"):
      > By answering all the questions you can generate AppStream-compatible markup
      > for the upstream AppData file.
      > If the user is able to "enable" NSFW or "adult" content, then this should be
      > included in the assessment even if it is turned off by default.
      > What type of component are you generating content for:
      => Application that can connect to the Internet
      > OARS has multiple versions, and the newer versions include more questions
      > involving specific cultural and religious sensitivities. What version of OARS
      > metadata do you want to produce:
      => 1.0 (works with all clients)
      > Advertising
      > Defined as the activity of producing advertisements for commercial products or
      > services.
      > For example, this would include banners showing the Coca-Cola logo shown in a
      > Soccer game.
      => None
      > Gambling
      > Defined as taking a risky action in the hope of a desired result.
      > For example, this would include spinning a wheel to get in-app credits.
      => None
      > In-App Purchases
      > Defined as items or points that a user can buy for use within a virtual world
      > to improve a character or enhance the playing experience.
      => None
      > Online Text-only Messaging
      > Defined as any messaging system connected to the Internet.
      => None
      > Online Audio and Video Messaging
      > Defined as any multimedia messaging system connected to the Internet.
      => None
      > Contact Details
      > Defined as sharing identifiable details with other users to allow out-of-band
      > communication.
      => None
      > Information Sharing
      > Defined as sharing information with a legal entity typically used for
      > advertising or for sending back diagnostic data.
      > For example, this would include sending your purchasing history to Amazon.
      => None
      > Location Sharing
      > Defined as sharing your physical real-time location.
      > For example, this would include uploading the GPS co-ordinates of your current
      > location. NOTE: This does not include heuristic based location services, e.g.
      > GeoIP and others.
      => None
      > The following markup can be pasted into the existing application AppData file.
      > <content_rating type="oars-1.0" />
      Change-Id: I063484d8031892c20f88999c5a9beeae3666511c
      Reviewed-on: https://gerrit.libreoffice.org/72581
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
  2. 10 May, 2019 1 kayıt (commit)
  3. 25 Nis, 2019 1 kayıt (commit)
    • Stephan Bergmann's avatar
      tdf#122244 Put InfoPlist.strings files at correct places on macOS · 7a08bfea
      Stephan Bergmann yazdı
      Don't know how this got broken, presumably somewhere along the line from
      01344a8c "convert sysui to gbuild and add to
      tail_build" through 4430ace3 "tdf#90753:
      AutoInstall more packages" to the current state, where a spurious bin directory
      containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
      placed in instdir/ and in the root window of .dmg files.
      As discussed in the <https://developer.apple.com/library/archive/documentation/
      AboutInformationPropertyListFiles.html> "Localizing Property List Values"
      section, those InfoPlist.strings files shall apparently be placed into the
      Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
      needed in the past to transport their payload to the proper places in the
      installation set, and are now obsolete.)
      The list of Apple language IDs for the *.lproj directories was already
      duplicated in Makefile.in (test-install target) and
      solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
      those lists should all be consolidated.  Also, mapping from our language IDs
      (see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
      from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
      added en-US to the gb_WITH_LANG list of languages for which to generate
      InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
      non-localized strings stored in Info.plist itself).  But as mentiond, those
      InfoPlist.strings files are all empty anyway (which may be due to another bug?),
      so it shouldn't matter much---at least for now---what
      Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
      installation set.
      Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
      Reviewed-on: https://gerrit.libreoffice.org/71277
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
  4. 24 Mar, 2019 1 kayıt (commit)
  5. 05 Mar, 2019 1 kayıt (commit)
  6. 17 Ara, 2018 1 kayıt (commit)
  7. 14 Kas, 2018 1 kayıt (commit)
  8. 24 Eki, 2018 1 kayıt (commit)
  9. 29 Agu, 2018 1 kayıt (commit)
  10. 27 Agu, 2018 1 kayıt (commit)