rq only compiles with ruby 1.8 which we don't distribute anymore.
the source is dead.
there is a 1.9 branch over https://github.com/pjotrp/rq that hasn't been
touched for 4 years.
Overview of the updated versions:
stable: 48.0.2564.116 -> 49.0.2623.75
beta: 49.0.2623.63 -> 49.0.2623.75
dev: 50.0.2657.0 -> 50.0.2661.11
Stable and beta are now in par because of the release of a major stable
update.
The release addresses 26 security vulnerabilities, the following with an
assigned CVE:
* CVE-2016-1630: Same-origin bypass in Blink. Credit to Mariusz
Mlynski.
* CVE-2016-1631: Same-origin bypass in Pepper Plugin. Credit to Mariusz
Mlynski.
* CVE-2016-1632: Bad cast in Extensions. Credit to anonymous.
* CVE-2016-1633: Use-after-free in Blink. Credit to cloudfuzzer.
* CVE-2016-1634: Use-after-free in Blink. Credit to cloudfuzzer.
* CVE-2016-1635: Use-after-free in Blink. Credit to Rob Wu.
* CVE-2016-1636: SRI Validation Bypass. Credit to Ryan Lester and
Bryant Zadegan.
* CVE-2015-8126: Out-of-bounds access in libpng. Credit to
joerg.bornemann.
* CVE-2016-1637: Information Leak in Skia. Credit to Keve Nagy.
* CVE-2016-1638: WebAPI Bypass. Credit to Rob Wu.
* CVE-2016-1639: Use-after-free in WebRTC. Credit to Khalil Zhani.
* CVE-2016-1640: Origin confusion in Extensions UI. Credit to Luan
Herrera.
* CVE-2016-1641: Use-after-free in Favicon. Credit to Atte Kettunen of
OUSPG.
The full announcement which also includes the link to the bug tracker
can be found here:
http://googlechromereleases.blogspot.de/2016/03/stable-channel-update.html
Also, the 32bit Chrome package needed for the Flash and Widevine plugins
doesn't exist anymore, because Google has dropped support for 32bit
distros, see here for the announcement:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/FoE6sL-p6oU
On our end, we need to fix the patch for the plugin paths to work for
the latest dev channel. The change is very minor, because the
nix_plugin_paths_46.patch only doesn't apply because of an iOS-related
ifdef.
Built and tested on my Hydra at:
https://headcounter.org/hydra/eval/311511
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #13665
Comparing the current version with the version in sources list and
accidentally swapping the version arguments isn't going to get very far
because every new version that will come up will then be treated as "we
already have that version".
So we're now using versionOlder and also a check whether the version is
the *same* as the one in sources.nix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
No changes in functionality, but to make future source updates a bit
easier on the eyes when viewing the diff.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The update.sh shell script now is only a call to nix-build, which does
all the hard work of updating the Chromium source channels and the
plugins. It results in a store path with the new sources.nix that
replaces the already existing sources.nix.
Along the way, this has led to a quite massive workaround, which abuses
MD5 collisions to detect whether an URL is existing, because something
like builtins.tryEval (builtins.fetchurl url) unfortunately doesn't
work. Further explanations and implementation details are documented in
the actual implementation.
The drawback of this is that we don't have nice status messages anymore,
but on the upside we have a more robust generation of the sources.nix
file, which now also should work properly on missing upstream
sources/binaries.
This also makes it much easier to implement fetching non-GNU/Linux
versions of Chromium and we have all values from omahaproxy available as
an attribute set (see the csv2nix and channels attributes in the update
attribute).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As stated in the parent commit, the 32bit Chrome package is not
available upstream, so let's at least provide the SHA256 hash for the
64bit package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Until now, if we have a failure to fetch either the 32bit Debian package
or the 64bit Debian package, neither of these will be put into
sources.nix.
Unfortunately the beta/dev channels do not have a 32bit Debian package,
so even though there is a 64bit Debian package available we don't get
plugins *at* *all*.
This also introduces a nicer error message rather than just failing with
an assertion in fetchurl because we did not provide url/urls.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
From the debian security mailing list:
Several vulnerabilities have been discovered in the chromium web browser.
CVE-2016-1622
It was discovered that a maliciously crafted extension could bypass
the Same Origin Policy.
CVE-2016-1623
Mariusz Mlynski discovered a way to bypass the Same Origin Policy.
CVE-2016-1624
lukezli discovered a buffer overflow issue in the Brotli library.
CVE-2016-1625
Jann Horn discovered a way to cause the Chrome Instant feature to
navigate to unintended destinations.
CVE-2016-1626
An out-of-bounds read issue was discovered in the openjpeg library.
CVE-2016-1627
It was discovered that the Developer Tools did not validate URLs.
CVE-2016-1628
An out-of-bounds read issue was discovered in the pdfium library.
CVE-2016-1629
A way to bypass the Same Origin Policy was discovered in Blink/WebKit,
along with a way to escape the chromium sandbox.
They're still enabled by default, but now can be disabled.
Python has not been made optional due to the additional complexity of:
- python2 vs python3
- pync support on Darwin
Making Python support optional should be revisited at another time.
Fixes: #12840
Related to: 61042a561042a5 changes the replaced token from $something to @something@. This
commit repeats that change in one additional location used by the
WideVine plugin
Extract the rsync source fetching into its own expression and use that
expression to fetch the same source for rsync and rrsync.
rrsync is just copied from the support folder of rsync, no configure or build
needed. Also none of the rsync patches are needed. Only the path to rsync needs
to be patched into rrsync.
Bugfix release, mainly for Carddav regression over EWS, also includes an NTLM support enhancement.
Enhancement:
- Improve NTLM support try to send hostname as workstation name instead of UNKNOWN
- Fix notification dialog message
- Prepare ExchangeSessionFactory refactoring
- Fix typo in french translation
- Fix broken Sourceforge link in About dialog
Carddav:
- Carddav: fix regression on contact update with empty field triggering DeleteItemField
(cherry picked from commit cf327c3dcfd442cea4368d76c59f72dcd5da6768)
[Bjørn: Cherry-picked from release-15.09 to master. (I guess merging
first to release-15.09 was a mistake.)]
There is already a pull request from @colemickens, who has just reversed
the variable references $flash and $flashVersion but the fix is kinda
fragile as he points out himself in #12713.
The reason the wrong substition was made is that both variables begin
with the same name and we do a simple replace instead of a more
complicated one using builtins.match.
So staying simple but to still not raising issues with other variables
that begin with the same name I'm now using @var@ instead, like we use
in substituteAll and other substituters (like the ones in CMake or
autotools) deal with it.
Note that I'm not using $var$ here to make sure it doesn't get confused
with real shell variables.
So with this fix in place, the wrapper now has the following flags:
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=20.0.0.294
Previously we had (#12710):
--ppapi-flash-path=/nix/store/.../lib/libpepflashplayer.so
--ppapi-flash-version=/nix/store/...-binary-plugins-flashVersion
Thanks to @colemickens for reporting and putting up a pull request.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #12710Fixes: #12713
This reverts commit f7af2272a2.
We're going to fix#12710 properly by reintroducing 38c77bb and fixing
the shell variable substitution.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is a maintenance release that brings the following changes:
- Fixes#287: media:content support broken
- Fixes#279: Rules not visible in searchdialog
- Fixes#83: Segfault when sorting feeds in folder
- Fixes#302: Broken compilation with --disable-notify
- Fixes CVE-2016-1612 CVE-2016-1613 CVE-2016-1614 CVE-2016-1615
CVE-2016-1616 CVE-2016-1617 CVE-2016-1618 CVE-2016-1619 CVE-2016-1620.
- Moves chromium stable and beta channels up one version major.
vcunat made dev channel stay for now, as it wouldn't download otherwise.
This is most of PR #12717.
This package is deprecated and superseeded by links2 which also provides the
links binary this maintaining backwards-compatibility.
Debian removed links back in 2008:
https://packages.qa.debian.org/l/links.htmlFixes#12623.
This will probably be mandatory soon, and is a step in the right
direction. Removes the deprecated meta.version, and move some meta
sections to the end of the file where I should have put them in
the first place.
Currently we have `kde4.konversation` which is version 1.5 of
Konversation.
This adds `kde5.konversation` which is version 1.6 and builds
against the latest KDE Frameworks 5.
Last maintained in 2013. Building fails due to vanished sources.
Upstream has the following to say:
“As of February 11th 2015, Fuze will no longer support a native
Linux-based client. This means that any customers attempting to
install or use our previous Linux client will be unable to do
so. There are currently no plans to create an updated version
of the Linux client for Fuze. For Linux based customers that
still wish to use Fuze, we recommend that you try our browser
client.” -- https://support.fuze.com/hc/en-us/articles/201527877-Does-Fuze-Support-Linux-
Never marked as broken, but has been so for quite some time.
Working on Chromium really drives me nuts due to its build time, also I
really don't have quite a lot of time these days to properly maintain it
anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has been introduced by me in 690a845 and discovered by @vcunat in
his comment over at:
690a845de9 (commitcomment-14209868)
It's really a bit ugly to have builds running during evaluation, but
back when I made that commit the reason was to avoid having to shell
quote the hell out of it (see the comment in mkPluginInfo for the
reason).
Now we propagate plugin flags and environment variables as a list of
arguments in a plain file that's appended verbatim to makeWrapper, so
it shouldn't do any builds anymore during instantiation.
I have tested this with both just WideVine and just Flash enabled as
well as both in combination and none of the plugins and the output seems
correct. However I didn't test to run Chromium with the new
implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Vladimír Čunát <vcunat@gmail.com>
I'm not certain about this, so I'm trying for firefox only.
Rationale: it might be confusing to see two firefox-${version} instances
in logs or paths, so I wanted to differentiate them.
- I chose to keep `browser-unwrapped` attributes so that it's much
easier to override parameters for the browser (through `packageOverrides`).
- Aliases `browserWrapper` are retained for now, as usual.
The official repository has last been updated in 2013,
meanwhile there are a lot of issues like non-existant
certificate verification. The debian repository is actively
maintained and already includes most of our custom patches,
so we use it instead.
Fixes#12257, closes#12259.
vcunat appended commit date to version.
- I don't think that amount of code belonged into all-packages.nix.
- Now the default name of the wrapped package is identical
with the command that runs the browser.
- Other defaults were changed according to how the wrapper is
(almost always) used.
- `meta` is improved: mostly inherited with priority above
the unwrapped package.
The Bitmessage protocol v3 became mandatory on 16 Nov 2014 and notbit does not support it, nor has there been any activity in the project repository since then.
http://hydra.nixos.org/eval/1234895
The mass errors on Hydra seem transient; I verified ghc on i686-linux.
Only darwin jobs are queued ATM. There's a libpng security update
included in this merge, so I don't want to wait too long.
This improves our Bundler integration (i.e. `bundlerEnv`).
Before describing the implementation differences, I'd like to point a
breaking change: buildRubyGem now expects `gemName` and `version` as
arguments, rather than a `name` attribute in the form of
"<gem-name>-<version>".
Now for the differences in implementation.
The previous implementation installed all gems at once in a single
derivation. This was made possible by using a set of monkey-patches to
prevent Bundler from downloading gems impurely, and to help Bundler
find and activate all required gems prior to installation. This had
several downsides:
* The patches were really hard to understand, and required subtle
interaction with the rest of the build environment.
* A single install failure would cause the entire derivation to fail.
The new implementation takes a different approach: we install gems into
separate derivations, and then present Bundler with a symlink forest
thereof. This has a couple benefits over the existing approach:
* Fewer patches are required, with less interplay with the rest of the
build environment.
* Changes to one gem no longer cause a rebuild of the entire dependency
graph.
* Builds take 20% less time (using gitlab as a reference).
It's unfortunate that we still have to muck with Bundler's internals,
though it's unavoidable with the way that Bundler is currently designed.
There are a number improvements that could be made in Bundler that would
simplify our packaging story:
* Bundler requires all installed gems reside within the same prefix
(GEM_HOME), unlike RubyGems which allows for multiple prefixes to
be specified through GEM_PATH. It would be ideal if Bundler allowed
for packages to be installed and sourced from multiple prefixes.
* Bundler installs git sources very differently from how RubyGems
installs gem packages, and, unlike RubyGems, it doesn't provide a
public interface (CLI or programmatic) to guide the installation of a
single gem. We are presented with the options of either
reimplementing a considerable portion Bundler, or patch and use parts
of its internals; I choose the latter. Ideally, there would be a way
to install gems from git sources in a manner similar to how we drive
`gem` to install gem packages.
* When a bundled program is executed (via `bundle exec` or a
binstub that does `require 'bundler/setup'`), the setup process reads
the Gemfile.lock, activates the dependencies, re-serializes the lock
file it read earlier, and then attempts to overwrite the Gemfile.lock
if the contents aren't bit-identical. I think the reasoning is that
by merely running an application with a newer version of Bundler, you'll
automatically keep the Gemfile.lock up-to-date with any changes in the
format. Unfortunately, that doesn't play well with any form of
packaging, because bundler will immediately cause the application to
abort when it attempts to write to the read-only Gemfile.lock in the
store. We work around this by normalizing the Gemfile.lock with the
version of Bundler that we'll use at runtime before we copy it into
the store. This feels fragile, but it's the best we can do without
changes upstream, or resorting to more delicate hacks.
With all of the challenges in using Bundler, one might wonder why we
can't just cut Bundler out of the picture and use RubyGems. After all,
Nix provides most of the isolation that Bundler is used for anyway.
The problem, however, is that almost every Rails application calls
`Bundler::require` at startup (by way of the default project templates).
Because bundler will then, by default, `require` each gem listed in the
Gemfile, Rails applications are almost always written such that none of
the source files explicitly require their dependencies. That leaves us
with two options: support and use Bundler, or maintain massive patches
for every Rails application that we package.
Closes#8612
It is a little weird that chromium has chromium, chromiumBeta,
chromiumDev but this one is google-chrome, google-chrome-beta,
google-chrome-dev. Not quite sure what the best resolution is, if any.
Changes:
- Fix: XML output had extra commas, broken since previous version
- Fix: unintended shared pointer modification in mosecs() sometimes resulted
in wrong month name to be shown for the current month
- Fix: possible buffer overflow in /proc/net/dev parsing, requires corrupted
content in /proc/net/dev or use of address sanitizer
- Use ANSI escape codes in -l and -tr modes for cursor location manipulation
instead of printing backspaces, hide cursor while output is active
- Improve database import robustness
- Improve support for Asian UTF-8 date strings
- Replace hand written Makefiles with Autotools
- Add --alwaysadd parameter to daemon for allowing automatic addition of
interfaces even if the database directory was populated during startup
Built and run Beta and Stable locally. Dev is surrently superseded by Stable so
it doesn't matter much.
- Dev: 47.0.2508.0 -> 48.0.2564.22
- Beta: 46.0.2490.64 -> 48.0.2564.23
- Stable: 45.0.2454.101 -> 47.0.2526.73
Changed the SSL dependencies to the supported configuration on Linux (according
to Torne @Freenode/#chromium-support).
- NSS is a dependency since it is used to access the ceritiface store.
- Dropped system OpenSSL support, the bundled BoringSSL is used.
This probably fixes issue #10555. Note that without this adjustment the build
fails even.
Dropped uneeded old patches.
Upgrade message: http://sourceforge.net/p/davmail/mailman/message/34597887/
This new release contains a lot of fixes from user feedback, a new
-notray command line
option to force window mode and avoid tricky tray icon issues on Linux
and native
smartcard support on Windows.
Caldav:
- Caldav: Map additional priority levels
- Caldav: fix missing LAST-MODIFIED in events
Enhancements:
- Improved tray icon with alpha blend
- Fix imports
- Prepare mutual SSL authentication between client and DavMail
implementation
- Implement -notray command line option as a workaround for broken SWT
and Unity issues
- Change warning messages to debug in close method
- Improve client certificate dialog, build description from certificate
- Exclude client certificates not issued by server provided issuers list
IMAP:
- IMAP: Additional translations and doc for new IMAP setting
- IMAP: Merge patch by Mauro Cicognini, add a new setting to always send
approximate message in RFC822.SIZE to avoid downloading full message body
- IMAP: fix regression with quotes inside folder names
- IMAP: handle quotes inside folder names correctly
OSX:
- OSX link local address on loopback interface
- Exclude arguments starting with dash to avoid patch 38 regression on OSX
Documentation:
- Doc: Document -notray option
- Switch to OpenHub instead of Ohloh
EWS:
- EWS: prepare distribution list implementation
- Fix#254 davmail.exchange.ews.EWSException:
ErrorIncorrectUpdatePropertyCount
Linux:
- Refresh davmail.spec, make RPM noarch
- Handle missing or broken SWT library
Windows:
- Windows: Make MSCAPI keystore type available in Settings for Windows
native smartcard support
- Instantiate MSCAPI explicitly to access Windows Smartcards
- Enable native Windows SmartCard access through MSCAPI (no PKCS11
config required)
Carddav:
- Carddav: Test case for comma in ADR field
- Carddav: Do not replace comma on ADR field, see support request 255
- Caldav: Ignore missing END:VCALENDAR line on modified occurrences
- CardDav: Add empty property test case
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
As suggested the Google Chrome .deb file that is used for Chromium's plugins is reused.
vcunat removed lots of newlines, as the style was diverging from the
majority far too much (IHHO).
Close#10444, fixes#8749.
For some reason it's more involved than just setting gyp configuration,
we also have to set some definitions in widevine_cdm_version.h according
to the comments left in the file. Arch Linux does this already and so we
should probably just use the patch they created while getting Netflix to
work:
https://code.google.com/p/chromium/issues/detail?id=429452#c16
- systemd puts all into one output now (except for man),
because I wasn't able to fix all systemd/udev refernces
for NixOS to work well
- libudev is now by default *copied* into another path,
which is what most packages will use as build input :-)
- pkgs.udev = [ libudev.out libudev.dev ]; because there are too many
references that just put `udev` into build inputs (to rewrite them all),
also this made "${udev}/foo" fail at *evaluation* time
so it's easier to catch and change to something more specific
Built and tested locally.
nload is a console application which monitors network traffic and
bandwidth usage in real time. It visualizes the in- and outgoing traffic
using two graphs and provides additional info like total amount of
transfered [sic] data and min/max networking usage.
This commit adds `iptraf-ng` which is a fork of `iptraf`. The original
has not been updated in ~10 years. This fork is more modern but
development is a bit slow (last update to master 15 months ago).
Nevertheless, unlike `iptraf` this one doesn't barf around and works
properly.
Upstream changes to the build system required adjusting many packages'
dependencies. On the Nixpkgs side, we no longer propagate the dependency
on cmake (to reduce closure size), so downstream dependencies had to be
adjusted for most packages that depend on kdelibs.
The patch only applies for Firefox versions between 37.0 and 40.1.
Because we're on version 41.0 the changes are already included upstream
and thus the patch doesn't apply and is even unnecessary.
As for version 38.3 for ESR, the patch doesn't apply as well if compiled
with enableGTK3. Of course, this is a bit unfortunate but I don't have
the time right now to properly rebase the patch on 38.3.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: devhell <"^"@regexmail.net>
We were using HEAD for unreleased features. These features are now in
release builds so we should go back to using those. This also means we
won't have to deal with hash mismatches for all ruby packages.
Built and run successfully on local.
From the Changelog:
```
- GNU Readline
- OpenPGP support
- Message Carbons (xep-0280)
- Message Delivery Receipts (xep-0184)
- MUC Mediated Invitation support
- Configurable time formatting
- Option to show JIDs in roster
- Option to hide empty groups in roster
- Generate UUID for unnamed new MUC rooms
- Themable UI preference to indicate OTR and PGP messages
- Reformatted help
- devel: Added functional tests using libexpect and libstabber
```
It's another attempt to fix chromium builds.
See http://hydra.nixos.org/build/26086977/nixlog/4/raw
Unpacking sources is actually taking more than 2h so build fails.
Instead, rather build it remotely and then copy over the output as
we don't have limits for download time.
See 089bdce621 for reference
cc @aszlig
(cherry picked from commit cef54e7d67870ff68c9787ff60cd50ca4bf1d8af)
Signed-off-by: Domen Kožar <domen@dev.si>
This commit includes some rework since the original googlecode
repository redirects to the GitHub page.
Built and tested successfully on local.
From the Changelog:
```
* Wed Jun 11 2014 1.2
- A basic RSS reader which uses libmrss.
- Fix some 32bit platforms reporting 0 connected peers and unknown ETA.
- Resolve some GTK deprecations.
- Fix a crash in port test callback.
- Fix decimal marker in status bar version.
- Support for GeoIPCity.dat.
- Fix a crash when removing lots of columns (something changed in GTK).
- Optional and non-default support for validating SSL certs.
- Remove all GTK2 support.
- Allow alt-speed limits to override global speed limits in the statusbar
display.
```
Java's desktop integration on Linux relies on dlopen'ing some libraries (gtk2 or
gnome). This commit makes Java able to find gtk2, fixing the problem of Jitsi's
system tray icon not appearing.
Part of bug #4014.
Adds support for shared-mime-info to Claws, to fix attachments in
outgoing messages always having MIME type application/octet-stream
because Claws doesn't know where to look, instead complaining:
/nix/store/...-claws-mail-3.11.1/etc/mime.types: fopen: No such file or directory
Moreover, Claws relies on incoming MIME types for knowing when e.g. to
display an attached image, so sending application/octet-stream
unnecessarily is bad.
Tested against release-15.09.
