1. 19 Aug, 2016 1 commit
  2. 16 Aug, 2016 1 commit
  3. 14 Jul, 2016 1 commit
  4. 08 Jul, 2016 1 commit
  5. 07 Apr, 2016 1 commit
  6. 10 Mar, 2016 1 commit
    • Andrés G. Aragoneses's avatar
      build/windows: update gitorious URL to new github URL · 99c1eb12
      Andrés G. Aragoneses authored
      Gitorious service was discontinued. Now there's a read-only
      facade on its web-server that allows you to download the
      mirrored repo backups, but it may be soon disconnected, and
      anyway its SSL cert doesn't work. I've copied the repo to our
      new github location.
  7. 18 Feb, 2016 1 commit
  8. 25 Jan, 2016 1 commit
  9. 22 Jan, 2016 1 commit
  10. 19 Jan, 2016 1 commit
  11. 17 Jan, 2016 1 commit
  12. 23 Sep, 2015 1 commit
  13. 09 Sep, 2015 1 commit
  14. 07 Sep, 2015 1 commit
  15. 02 Sep, 2015 1 commit
  16. 30 Aug, 2015 1 commit
  17. 19 Aug, 2015 2 commits
  18. 10 Aug, 2015 3 commits
  19. 09 Aug, 2015 1 commit
  20. 08 Aug, 2015 1 commit
    • Andrés G. Aragoneses's avatar
      autogen.sh: call `make distclean` under the hood (bgo#741530) · 2dc66b1e
      Andrés G. Aragoneses authored
      As a sanity-check measure, it's useful that autogen.sh calls
      `make distclean` in case there are binaries of a previous
      compilation that could cause issues.
      In particular, bgo#741530 is actually a consequence of this:
      a developer (yours truly) switching to a stable branch to
      run a different version of banshee, but forgetting to remove
      the binaries from master-branch that were generated before,
      therefore mixing assemblies from one branch and the other.
      If this command fails because there were no makefiles at all
      (which is what happens at a clean checkout) then it will of
      course silently fail.
  21. 03 Aug, 2015 1 commit
  22. 26 Jul, 2015 1 commit
  23. 20 Jul, 2015 1 commit
  24. 17 Jul, 2015 1 commit
    • Bertrand Lorentz's avatar
      Update for dbus-sharp 0.8.1 & dbus-sharp-glib 0.6 · 37f949bc
      Bertrand Lorentz authored
      We now require both dbus-sharp 0.8.1 and dbus-sharp-glib 0.6.
      Switching to >=0.8 dbus-sharp was necessary as a first step
      towards fixing bgo#630110 ("Get single instance and remote
      control working on Win32"). But it's rather better to already
      require 0.8.1 instead of 0.8, because 0.8 had regressions (see
      These new versions of these dependencies have API/ABI breaks, so
      then their version in their pc files is raised from 1.0 to 2.0.
      Switching to these versions allow us to also make some cleanups:
      We were using an obsolete Bus.Session.Register which required a bus
      name, and it's now gone. This allows us to remove some
      DBusServiceManager.RegisterObject overloads that become unnecessary.
      As an additional consequence, we don't need the DBusExportable attribute
      anymore. It was used by classes implementing IDBusExportable to indicate
      their service name, which was then used for the bus name.
  25. 09 Jul, 2015 1 commit
    • Stephan Sundermann's avatar
      ThickClient: fix left menu in gtk3.14 (bgo#749960) · 5aef9d43
      Stephan Sundermann authored
      Rendering of the left sources panel got broken
      somewhere between gtk 3.10 and gtk 3.14, as some
      treeview rendering mechanisms might have changed:
      now OnRender is not called anymore when the width
      is 0; so let's call the base implementation of
      OnGetPreferredWidth() here instead.
      This fixes the main glitch about using Banshee
      2.9.x in Ubuntu 15.04, for example, which already
      bundles gtk 3.14.x.
  26. 07 Jul, 2015 4 commits
  27. 06 Jul, 2015 2 commits
  28. 03 Jul, 2015 1 commit
    • Andrés G. Aragoneses's avatar
      Revert "Migo: Fixed parsing RSSs with BOM (bgo#727432)" · 1bb41479
      Andrés G. Aragoneses authored
      This reverts commit 27f1135e.
      There were some problems with this patch:
      a) When improving the version that Marcin posted in bugzilla,
      in order to not hardcode UTF8 encoding, I incorrectly placed
      this logic inside an if block like this:
       if (s.StartsWith("<?xml")) {
      Given that the logic to remove the bom also asks for
       if (s.StartsWith(bom)) {
      You would think that the logic added to fix this bug
      would simply not work (because the condition that made
      the code flow enter into the parent block would make
      the second condition FALSE).
      However, surprisingly enough, the bom from the podcast
      example in bugzilla [0] is parsed as UTF8 and UTF8's
      ByteOrderMark's length is 1, and Mono returns true for
      both of the conditions above, even if bom is obviously
      not "<" (the first character of the "<?xml" string to
      check if the content is XML.
      I still don't understand how can this be possible, but
      the consequence of it is that the content is stripped
      from its first character, so all XML feeds received
      that started with "<?xml" were converted to a string
      starting with "?xml", which clearly resulted in a
      parsing error.
      Not sure if this is a Mono bug, and not sure this is
      fixed in newer versions, but with the version I'm using
      now (3.2.8) I cannot reproduce bug 727432, and this is
      a very widely used version of Mono (it comes with
      Ubuntu 14.04 LTS, 14.10, and 15.04). So I'm reverting
      the fix for this (until we figure out a better fix, and
      the exact environment to reproduce it), otherwise many
      more podcasts would be broken.
      [0] http://podcast.dr.dk/p1/rssfeed/orientering.xml
  29. 30 Jun, 2015 1 commit
  30. 27 Jun, 2015 1 commit
    • Andrés G. Aragoneses's avatar
      SourceMessage: fix race in access to actions collection (bgo#751582) · 7ad6e330
      Andrés G. Aragoneses authored
      This foreach() loop had the potential problem of a typical race
      throwing a 'System.InvalidOperationException: Collection was modified;
      enumeration operation may not execute.'
      The normal thing to do in these cases is just to make a copy of the
      collection (via the .ToArray() method, for instance), at the
      beginning of the loop. However, this approach alone:
      a) would have presented a new race between the check for null
      and the call to the ToArray method.
      b) wouldn't have worked at compile time because IEnumerable<X>
      doesn't have this method (List<X> does).
      The proper way to fix (a) involves also avoiding to have
      a null value. How? Initializing the field always at
      construction time of the SourceMessage class.
      This has the good side-effect of being able to remove all
      null-checks around this field and its wrapper property.
      WRT (b) we could have created a new list at the beginning
      of the foreach loop, but it's more practical to just do the
      copy in the SourceMessage class, because, in the end, a read
      access should also involve lock()ing, otherwise writers to
      the collection could race with the readers of it.
  31. 24 Jun, 2015 1 commit
  32. 21 Jun, 2015 2 commits