Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Alternative:
targetpackage.deepOverride { emacs = emacsNox; };
?
Could be slower and less convenient.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Peter, I guess you've missed the point. Even if the new version is stable and the test case works this does not mean that upgrading is stable. So consider commenting on this point, please. Neither does a failing test case mean the new version is less stable then the old - the warnings by "Mathijs Kwik" have been strong. Maybe I find time to actually test bup on my machine to see whether I can reproduce the problems found by him at least once. If 3 out of 4 month failed it should not be that hard. Does bup allow comparing its storage contents against a filesystem tree? I like bup because its simple and fast, but it should also be reasonable stable. > revert I would have liked anybody restarting the build once to see whether this alone triggers a race condition making it pass this time. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Aristid Breitkreuz writes:
> Try something more like this:
>
> {
> packageOverrides = pkgs:
> rec
> {
>emacs = pkgs.emacs24-nox;
>djr = pkgs.buildEnv {
>name = "djr";
>paths = with pkgs; [emacs mu];
>};
> };
> }
And note that the djr buildEnv is not really related to the fact that
you want to override emacs. It's just a better/more convenient way to
keep all your packages up to date.
But the following would suffice:
{ packageOverrides = pkgs:
{ emacs = pkgs.emacs24-nox; };
}
Or just
{ packageOverrides = pkgs:
{ emacs24 = pkgs.emacs24.override { withX = false; }; };
}
So we don't end up with lots of top-level variations in
all-packages.nix for emacs-without-gtk-but-with-alsa,
emacs-noimagemagick, and other combinations :)
>
>
> 2013/9/1 Danie Roux
>
>> On Sun, Sep 1, 2013 at 10:54 PM, Mathijs Kwik
>> wrote:
>> > Danie Roux writes:
>> >> mu has a dependency on emacs and I don't know how to make it believe
>> >> that emacs24-nox satisfies that dependency.
>> >
>> > You should probably use packageOverrides, see the nixpkgs.config option
>> > in the configuration.nix manpage.
>> >
>> > Or use it locally (in your user profile) as explained here:
>> > http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
>>
>> This was an attempt in that direction, which doesn't have the desired
>> effect:
>>
>> {
>> packageOverrides = pkgs:
>> let
>>emacs = pkgs.emacs24-nox;
>> in
>> rec
>> {
>>djr = pkgs.buildEnv {
>>name = "djr";
>>paths = with pkgs; [emacs mu];
>>};
>> };
>> }
>>
>> nix-env --dry-run -i djr
>>
>> --
>> Danie Roux
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
On Sun, Sep 1, 2013 at 11:03 PM, Aristid Breitkreuz wrote: > Try something more like this: Ah, that looks much better - thank you. The X dependencies are gone. It still forces the build of the emacs-24.3 derivation, instead of fetching it as a straight `nix-env -i emacs-24.3-nox` does. (The build causes a build of coretools, which currently fails for unknown reasons on my Darwin box - still looking into this). -- Danie Roux ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Try something more like this:
{
packageOverrides = pkgs:
rec
{
emacs = pkgs.emacs24-nox;
djr = pkgs.buildEnv {
name = "djr";
paths = with pkgs; [emacs mu];
};
};
}
2013/9/1 Danie Roux
> On Sun, Sep 1, 2013 at 10:54 PM, Mathijs Kwik
> wrote:
> > Danie Roux writes:
> >> mu has a dependency on emacs and I don't know how to make it believe
> >> that emacs24-nox satisfies that dependency.
> >
> > You should probably use packageOverrides, see the nixpkgs.config option
> > in the configuration.nix manpage.
> >
> > Or use it locally (in your user profile) as explained here:
> > http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
>
> This was an attempt in that direction, which doesn't have the desired
> effect:
>
> {
> packageOverrides = pkgs:
> let
>emacs = pkgs.emacs24-nox;
> in
> rec
> {
>djr = pkgs.buildEnv {
>name = "djr";
>paths = with pkgs; [emacs mu];
>};
> };
> }
>
> nix-env --dry-run -i djr
>
> --
> Danie Roux
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
On Sun, Sep 1, 2013 at 10:54 PM, Mathijs Kwik wrote:
> Danie Roux writes:
>> mu has a dependency on emacs and I don't know how to make it believe
>> that emacs24-nox satisfies that dependency.
>
> You should probably use packageOverrides, see the nixpkgs.config option
> in the configuration.nix manpage.
>
> Or use it locally (in your user profile) as explained here:
> http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once
This was an attempt in that direction, which doesn't have the desired effect:
{
packageOverrides = pkgs:
let
emacs = pkgs.emacs24-nox;
in
rec
{
djr = pkgs.buildEnv {
name = "djr";
paths = with pkgs; [emacs mu];
};
};
}
nix-env --dry-run -i djr
--
Danie Roux
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Danie Roux writes: > Hi all, > > How do I mark/alternative/indicate that emacs24-nox=emacs for any > package that requires emacs? > > This for example still wants to fetch all of X: > > nix-env --dry-run -iA nixpkgs.emacs24-nox nixpkgs.mu > > mu has a dependency on emacs and I don't know how to make it believe > that emacs24-nox satisfies that dependency. You should probably use packageOverrides, see the nixpkgs.config option in the configuration.nix manpage. Or use it locally (in your user profile) as explained here: http://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once > > Thanks, > > -- > Danie Roux > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Treating emacs24-nox as an alternative to emacs
Hi all, How do I mark/alternative/indicate that emacs24-nox=emacs for any package that requires emacs? This for example still wants to fetch all of X: nix-env --dry-run -iA nixpkgs.emacs24-nox nixpkgs.mu mu has a dependency on emacs and I don't know how to make it believe that emacs24-nox satisfies that dependency. Thanks, -- Danie Roux ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Hi Marc, >> I think it would be best to revert the update until the reason for the >> test failures on Hydra has been understood. > > I cannot do it (I don't have access). So do as you wish. okay, I've reverted the patch to fix the git-annex build. Please re-submit an updated version as soon as you have the chance. I'll run test builds of the new patch, too, to help stabilize the update. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Excerpts from Peter Simons's message of Sun Sep 01 18:11:59 +0200 2013: > I think it would be best to revert the update until the reason for the > test failures on Hydra has been understood. I cannot do it (I don't have access). So do as you wish. I personally think its better to have two versions: - the old with a comment "peter is using it, ask him if you want to change something" - the new one (maybe restart the build) to learn more about the failure. The revert is not that easy, because I added a common test case. That's why I think its easier to additionally get back the old version. If you want I can prepare a patch Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
On Sun, Sep 1, 2013 at 7:18 PM, Lluís Batlle i Rossell wrote: > On Sun, Sep 01, 2013 at 06:37:43PM +0200, Domen Kožar wrote: > > Hi all, > > > > I've updated libreoffice to latest stable (released few days ago). There > > are two caveats though: > > Great! :) > > > - Due to help being translated to so many packages total size when > unpacked > > is 2.1G (help is 1.4G). Any objections for making help optional? > > The build expression used to have a list of languages to include. Does that > apply to 'help'? > Yup. I would just put help/translations stuff into separate derivation and not bother hydra to build it. I'll open an issue to track that. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
On Sun, Sep 01, 2013 at 06:37:43PM +0200, Domen Kožar wrote: > Hi all, > > I've updated libreoffice to latest stable (released few days ago). There > are two caveats though: Great! :) > - Due to help being translated to so many packages total size when unpacked > is 2.1G (help is 1.4G). Any objections for making help optional? The build expression used to have a list of languages to include. Does that apply to 'help'? Regards, Lluís ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
On Sun, Sep 1, 2013 at 7:04 PM, Domen Kožar wrote: > > > > On Sun, Sep 1, 2013 at 6:59 PM, Mathijs Kwik > wrote: >> >> Domen Kožar writes: >> >> > Hi all, >> > >> > I've updated libreoffice to latest stable (released few days ago). >> >> Thanks for this! >> libreoffice probably isn't the easiest package to maintain :) > > > Don't mention all the fun :) > >> >> >> > There are two caveats though: >> > >> > - Due to help being translated to so many packages total size when >> > unpacked >> > is 2.1G (help is 1.4G). Any objections for making help optional? >> >> Do we keep English help? >> And an option to install all others? >> I don't think we need more fine grained selections. >> >> This might be a nice target for multiple-outputs though. >> That way, the core (with english help) is shared, meaning people who >> select the all-languages option won't need to build everything from >> scratch if hydra provides both outputs. > > > We could build only English help for now and have that as parameter. When > multiple-outputs branch is merged, we can make the next step :) That branch is for splitting huge parts of the stdenv and other big packages. The multiple-outputs nix functionality itself has been available for some time and is already being used by some packages (including mesa). So no need to wait for multiple-outputs to merge. > >> >> >> > >> > - libreoffice has quite some external dependencies and the way we build >> > them now is messy (we just fetch all of them inside and run make), there >> > is >> > space for improvements >> > >> > Domen >> > ___ >> > nix-dev mailing list >> > nix-dev@lists.science.uu.nl >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> And just curious... >> Why upgrade to 4.0, while 4.1 is out? >> I would expect skipping a version would save some work, but maybe going >> step-by-step it's easier to follow dependency/build-system changes. > > > 4.1 is still considered somewhat not final (from libreoffice.org: This > version of LibreOffice is prepared with care and presented with pride by the > LibreOffice community. PLEASE NOTE that, since this is the very second > version in the series, make sure to read the release notes (under "Handy > resources").). > > I'd stick to using stable releases, but we could have a "libreoffice_latest" > expression in nixpkgs for testing. > Only if that doesn't take twice your time. Honestly, I never missed anything using 3.6, it's not that office tools are on an invention-spree :P ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
On Sun, Sep 1, 2013 at 6:59 PM, Mathijs Kwik wrote: > Domen Kožar writes: > > > Hi all, > > > > I've updated libreoffice to latest stable (released few days ago). > > Thanks for this! > libreoffice probably isn't the easiest package to maintain :) > Don't mention all the fun :) > > > There are two caveats though: > > > > - Due to help being translated to so many packages total size when > unpacked > > is 2.1G (help is 1.4G). Any objections for making help optional? > > Do we keep English help? > And an option to install all others? > I don't think we need more fine grained selections. > > This might be a nice target for multiple-outputs though. > That way, the core (with english help) is shared, meaning people who > select the all-languages option won't need to build everything from > scratch if hydra provides both outputs. > We could build only English help for now and have that as parameter. When multiple-outputs branch is merged, we can make the next step :) > > > > > - libreoffice has quite some external dependencies and the way we build > > them now is messy (we just fetch all of them inside and run make), there > is > > space for improvements > > > > Domen > > ___ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > And just curious... > Why upgrade to 4.0, while 4.1 is out? > I would expect skipping a version would save some work, but maybe going > step-by-step it's easier to follow dependency/build-system changes. > 4.1 is still considered somewhat not final (from libreoffice.org: This version of LibreOffice is prepared with care and presented with pride by the LibreOffice community. PLEASE NOTE that, since this is the very second version in the series, make sure to read the release notes (under "Handy resources").). I'd stick to using stable releases, but we could have a "libreoffice_latest" expression in nixpkgs for testing. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Libreoffice update to 4.0.5.2
Domen Kožar writes: > Hi all, > > I've updated libreoffice to latest stable (released few days ago). Thanks for this! libreoffice probably isn't the easiest package to maintain :) > There are two caveats though: > > - Due to help being translated to so many packages total size when unpacked > is 2.1G (help is 1.4G). Any objections for making help optional? Do we keep English help? And an option to install all others? I don't think we need more fine grained selections. This might be a nice target for multiple-outputs though. That way, the core (with english help) is shared, meaning people who select the all-languages option won't need to build everything from scratch if hydra provides both outputs. > > - libreoffice has quite some external dependencies and the way we build > them now is messy (we just fetch all of them inside and run make), there is > space for improvements > > Domen > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev And just curious... Why upgrade to 4.0, while 4.1 is out? I would expect skipping a version would save some work, but maybe going step-by-step it's easier to follow dependency/build-system changes. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Libreoffice update to 4.0.5.2
Hi all, I've updated libreoffice to latest stable (released few days ago). There are two caveats though: - Due to help being translated to so many packages total size when unpacked is 2.1G (help is 1.4G). Any objections for making help optional? - libreoffice has quite some external dependencies and the way we build them now is messy (we just fetch all of them inside and run make), there is space for improvements Domen ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Marc Weber wrote: > Should we keep both versions then, Peter? I think it would be best to revert the update until the reason for the test failures on Hydra has been understood. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Excerpts from Peter Simons's message of Sun Sep 01 15:46:15 +0200 2013: > yes, I depend on bup. Or rather, I depend on git-annex, which depends on > bup. So it would be great to keep bup in a working state. Should we keep both versions then, Peter? bup works, the test suite passed here and Evgeny Egorochkin reported the same. I tjust failed (for wahtever reason) on the buildfarm. I didn't investigate yet. I know that my "custom test case" will only catch the very very obvious problems. It does not backup 30G VM images or the like. But its better than having nothing. But I agree that creating an even nicer test suite eg based on haskell quickcheck would be even nicer. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Hi Marc, > Is anybody depending on the tool or do I have a couple of days to > investigate? yes, I depend on bup. Or rather, I depend on git-annex, which depends on bup. So it would be great to keep bup in a working state. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
On Sun, Sep 1, 2013 at 3:00 PM, Marc Weber wrote: > Excerpts from Mathijs Kwik's message of Sun Sep 01 14:51:09 +0200 2013: >> I would like to warn you for bup though. >> I've used it for daily backups for at least half a year. > Well - I guess you should have started a new repo each month .. That's what I did. For at least 6 months :) But after the third month, I thought it would be a nice tryout to see if restoring worked as advertised. So before throwing the previous month away, I used it for a restore and found out it had nothing :( After noticing this 2 months in a row, I started checking "bup ls" daily, but didn't hit the issue. After starting over again (next month) the daily bup ls check did notice my repo get killed after 18 days or so. I could not find anything special in the logs and in the repo, but of course I do not have a backup of my repo to check for differences. Also, issues like this are fairly hard to reproduce (to file bug reports) and as backups contain quite some private data, providing snapshots or machine access to devs is not an option. > >> I've started over a few times, thinking it was something I messed up >> or because of version upgrades, but it happened more than once. >> Currently, I moved to using "btrfs send", which is awesome, but >> somewhat experimental too :) > Didn't knew about it. > >> Anyway, at least when it fails, it reports about it :) >> supports deleting old revisions > I've added this as warning. If you think you should have a new full > backup each month anyway, then it does not matter that much. It does, for me, it happened 3 out of 4 months. But of course this might depend on my data. All I'm saying is: automate regular checking the consistency of your repo > > So what do you do now? > btrfs send on the machine, and btrfs receive on the backup machine? Well of course it all starts with btrfs snapshots. I do them every 6 hours, as they are so cheap. They are taken in an instant, take up very little space if you don't change a lot on disk, and far less than block-based snapshotting (lvm) gives you. Also, you do not have to reserve space for them upfront (live lvm). I sync these snapshots with my backup machine daily, which itself sync my most important stuff to an off-site cloud vps overnight. The cool part is: this all happens with the same tools and with 1 on-disk format (normal, accessible volumes). "btrfs send" itself works incrementally (and even has settings where you can point out which other older snapshots the receiving end has, so it can cheat if you put back data that you had some days ago, but no longer with the last snapshot). This not only means the transfers are relatively small, but by using the fact that btrfs is really just 1 big journal, it does not need to scan everything to find out what has changed. Every other backup solution needs to do this, which will take a long time (and slow your system) if you have a few gigs of data, shattered over many thousands of files. Of course they can cheat by looking at ctimes/atimes or some index they keep, but it still takes a lot of time and those cheats can lead to data loss if you happen to use software that changes file contents, while keeping ctime/mtime/atime and size the same. Lastly, I employ a simple cleaner cronjob on all machines. So I only keep the 6-hour snapshots on my laptop for 3 days, while my backup system throws them out and only keeps 1 per day for up to a week, it keeps 1 per week for up to 2 months. The off-site VPS only keeps the most recent one (as cloud disk space is relatively pricey). So you see these locations have different data-safety purposes. The local ones are for when I make a mistake and find out quickly. The ones on the backup machine are there for longer-term backup, and mainly provides RAID, which my laptop doesn't provide. The off-site backup is only there in case my house explodes or something, so it doesn't need history. So the nice thing is that all these purposes are served by a single tool. > >> and does not have a separate on-disk format like bup (which >> effectlively doubles space requirements if you want your bup history >> available on the same machine as your live data). > I compared a use case (500 MB with many git repos) and it was not that > bad - eg compared tar j or storebackup - but fastest (initial and > incremental backup). The initial backup was 4 times faster. I'm not talking about the stuff bup keeps locally. I'm mainly talking about the real repo size. I know it is able to compress normal files quite well. But try making a bup repo of your 100g+ music collection. It will take up another 95g at least, which is wasteful if you're on a laptop with a 160g ssd or something. Of course you decide not to use bup for your music (use rsync for that), or to only make backups to a remote bup repo and use some snapshotting solution locally (for protecting against mistakes), but then you end up using 3 tools > > It could be a little risk tr
Re: [Nix-dev] bup - test suite
Excerpts from Mathijs Kwik's message of Sun Sep 01 14:51:09 +0200 2013: > I would like to warn you for bup though. > I've used it for daily backups for at least half a year. Well - I guess you should have started a new repo each month .. > I've started over a few times, thinking it was something I messed up > or because of version upgrades, but it happened more than once. > Currently, I moved to using "btrfs send", which is awesome, but > somewhat experimental too :) Didn't knew about it. > Anyway, at least when it fails, it reports about it :) > supports deleting old revisions I've added this as warning. If you think you should have a new full backup each month anyway, then it does not matter that much. So what do you do now? btrfs send on the machine, and btrfs receive on the backup machine? > and does not have a separate on-disk format like bup (which > effectlively doubles space requirements if you want your bup history > available on the same machine as your live data). I compared a use case (500 MB with many git repos) and it was not that bad - eg compared tar j or storebackup - but fastest (initial and incremental backup). The initial backup was 4 times faster. It could be a little risk trusting btrfs as main fs and as backup fs :) If you get a kernel which is bad it could destroy both .. > https://github.com/bluescreen303/bluenix/blob/master/pkgs/kernel/btrfs-updates-against-3.10.7.patch > , which is just a plain "git diff" patch comparing mainline with > linux-btrfs. If nobody is heavily depending on it - then the build failure is not that bad. So I'll just wait. bup is closer to a release anyway. I was a little bit surprised that it says "You can fuse the backup" - but only got 00/0ef234e like files .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] google-talk-plugin is broken?
I'm not sure. It's been this way for quite a while and I've got the latest versions of Chromium and google-talk-plugin. On Sep 1, 2013 2:28 PM, "Cillian de Róiste" wrote: > Hi Kirill, > > I think the path error is bogus, it's working fine here, can it be that > you just need to update? > > Cheers, > Cillian > > > On Sat, Aug 31, 2013 at 11:21 AM, Kirill Elagin wrote: > >> Here is Chromium console output: >> >> ~~~ >> [000:000] Browser XEmbed support present: 1 >> [000:000] Browser toolkit is Gtk2. >> [000:001] Using Gtk2 toolkit >> [000:202] Starting client channel. >> [000:203] Warning(clientchannel.cc:436): Unreadable or no port file. >> Could not initiate GoogleTalkPlugin connection >> [000:203] Warning(clientchannel.cc:411): Could not initiate >> GoogleTalkPlugin connection >> [000:203] GoogleTalkPlugin not running. Starting new process... >> [000:203] Warning(optionsfile.cc:47): Load: Could not open file, err=2 >> [000:203] Warning(pluginutils.cc:251): Failed to get GoogleTalkPlugin >> path. Trying default. >> [000:207] Started GoogleTalkPlugin, >> path=/opt/google/talkplugin/GoogleTalkPlugin >> [000:207] Waiting for GoogleTalkPlugin to start... >> [000:686] Starting client channel. >> [000:686] Warning(clientchannel.cc:436): Unreadable or no port file. >> Could not initiate GoogleTalkPlugin connection >> [000:686] Warning(clientchannel.cc:411): Could not initiate >> GoogleTalkPlugin connection >> [000:687] GoogleTalkPlugin not running. Starting new process... >> [000:687] Warning(optionsfile.cc:47): Load: Could not open file, err=2 >> [000:687] Warning(pluginutils.cc:251): Failed to get GoogleTalkPlugin >> path. Trying default. >> [000:696] Started GoogleTalkPlugin, >> path=/opt/google/talkplugin/GoogleTalkPlugin >> [000:696] Waiting for GoogleTalkPlugin to start... >> [001:213] Attempting to connect to GoogleTalkPlugin... >> [001:213] Warning(clientchannel.cc:436): Unreadable or no port file. >> Could not initiate GoogleTalkPlugin connection >> [001:213] Warning(clientchannel.cc:411): Could not initiate >> GoogleTalkPlugin connection >> [001:213] Waiting for GoogleTalkPlugin to start... >> [001:718] Attempting to connect to GoogleTalkPlugin... >> [001:718] Warning(clientchannel.cc:436): Unreadable or no port file. >> Could not initiate GoogleTalkPlugin connection >> [001:718] Warning(clientchannel.cc:411): Could not initiate >> GoogleTalkPlugin connection >> [001:718] Waiting for GoogleTalkPlugin to start... >> [002:219] Attempting to connect to GoogleTalkPlugin... >> [002:219] Warning(clientchannel.cc:436): Unreadable or no port file. >> Could not initiate GoogleTalkPlugin connection >> [002:219] Warning(clientchannel.cc:411): Could not initiate >> GoogleTalkPlugin connection >> >> ~~~ >> >> The path is obviously wrong… >> >> >> -- >> Кирилл Елагин >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] google-talk-plugin is broken?
Hi, It's been a long time since I have used the plugin, but could it be that you haven't enabled chromium.enableGoogleTalkPlugin in nixpkgs.config (or ~/.nixpkgs/config.nix)? a! -- aszlig signature.asc Description: Digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
I no longer use bup. People that do can probably just revert your change locally. I would like to warn you for bup though. I've used it for daily backups for at least half a year. While it never gave any errors, I noticed that repositories broke after some time somehow. As in: they must probably still contain your data somewhere (judging sizewise and from the fact that nothing ever gets deleted), but accessing it (bup ls / bup web / restore) shows up as empty. I've started over a few times, thinking it was something I messed up or because of version upgrades, but it happened more than once. Currently, I moved to using "btrfs send", which is awesome, but somewhat experimental too :) I reported a few bugs, which got fixed (mostly), but still require some kernel patches that will not make it into 3.11. And even with those I believe I've hit an edge case, but haven't been able to reproduce with logging yet. Anyway, at least when it fails, it reports about it :) Furthermore it's ridiculously fast, supports deleting old revisions and does not have a separate on-disk format like bup (which effectlively doubles space requirements if you want your bup history available on the same machine as your live data). If you would like to try it out yourself, use https://github.com/bluescreen303/bluenix/blob/master/pkgs/kernel/btrfs-updates-against-3.10.7.patch , which is just a plain "git diff" patch comparing mainline with linux-btrfs. On Sun, Sep 1, 2013 at 2:32 PM, Marc Weber wrote: > I've updated bup adding two tests: a simple manual one which can be > implemented for all backup solutions easily, and I tried activating the > "make test" for bup. > > The make test succeeded on my machine and on Evgeny Egorochkin's > but failed on hydra. > > Is anybody depending on the tool or do I have a couple of days to > investigate? > > The quickest fix is commenting the line "make test" probably. > > Marc Weber > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] bup - test suite
I've updated bup adding two tests: a simple manual one which can be implemented for all backup solutions easily, and I tried activating the "make test" for bup. The make test succeeded on my machine and on Evgeny Egorochkin's but failed on hydra. Is anybody depending on the tool or do I have a couple of days to investigate? The quickest fix is commenting the line "make test" probably. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] google-talk-plugin is broken?
Hi Kirill, I think the path error is bogus, it's working fine here, can it be that you just need to update? Cheers, Cillian On Sat, Aug 31, 2013 at 11:21 AM, Kirill Elagin wrote: > Here is Chromium console output: > > ~~~ > [000:000] Browser XEmbed support present: 1 > [000:000] Browser toolkit is Gtk2. > [000:001] Using Gtk2 toolkit > [000:202] Starting client channel. > [000:203] Warning(clientchannel.cc:436): Unreadable or no port file. > Could not initiate GoogleTalkPlugin connection > [000:203] Warning(clientchannel.cc:411): Could not initiate > GoogleTalkPlugin connection > [000:203] GoogleTalkPlugin not running. Starting new process... > [000:203] Warning(optionsfile.cc:47): Load: Could not open file, err=2 > [000:203] Warning(pluginutils.cc:251): Failed to get GoogleTalkPlugin > path. Trying default. > [000:207] Started GoogleTalkPlugin, > path=/opt/google/talkplugin/GoogleTalkPlugin > [000:207] Waiting for GoogleTalkPlugin to start... > [000:686] Starting client channel. > [000:686] Warning(clientchannel.cc:436): Unreadable or no port file. > Could not initiate GoogleTalkPlugin connection > [000:686] Warning(clientchannel.cc:411): Could not initiate > GoogleTalkPlugin connection > [000:687] GoogleTalkPlugin not running. Starting new process... > [000:687] Warning(optionsfile.cc:47): Load: Could not open file, err=2 > [000:687] Warning(pluginutils.cc:251): Failed to get GoogleTalkPlugin > path. Trying default. > [000:696] Started GoogleTalkPlugin, > path=/opt/google/talkplugin/GoogleTalkPlugin > [000:696] Waiting for GoogleTalkPlugin to start... > [001:213] Attempting to connect to GoogleTalkPlugin... > [001:213] Warning(clientchannel.cc:436): Unreadable or no port file. > Could not initiate GoogleTalkPlugin connection > [001:213] Warning(clientchannel.cc:411): Could not initiate > GoogleTalkPlugin connection > [001:213] Waiting for GoogleTalkPlugin to start... > [001:718] Attempting to connect to GoogleTalkPlugin... > [001:718] Warning(clientchannel.cc:436): Unreadable or no port file. > Could not initiate GoogleTalkPlugin connection > [001:718] Warning(clientchannel.cc:411): Could not initiate > GoogleTalkPlugin connection > [001:718] Waiting for GoogleTalkPlugin to start... > [002:219] Attempting to connect to GoogleTalkPlugin... > [002:219] Warning(clientchannel.cc:436): Unreadable or no port file. > Could not initiate GoogleTalkPlugin connection > [002:219] Warning(clientchannel.cc:411): Could not initiate > GoogleTalkPlugin connection > > ~~~ > > The path is obviously wrong… > > > -- > Кирилл Елагин > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
