On Sep 15, 2014 1:56 AM, "Leonid Isaev" wrote:
> systemd's factory reset and atomic upgrades were explicitly stated to be
useful
> only in special situations, like embedded systems. Just because Archlinux
> systemd package enables them doesn't mean that the entire distribution
should
> be change a
On Sep 15, 2014 1:02 AM, "Nowaker" wrote:
> 1. Where is your data stored? /home? Or is it stored remotely?
It depends.
My server has its RAID arrays mounted for its data. My desktop on the other
hand basically just has /home for storage.
That is exactly what I need to back up.
> 2. How about d
Am 15.09.2014 00:54 schrieb "Nowaker" :
> Good point. I just did `pacman -Ql |grep -F ' /var'` to see how many
> files there are. 99.7% of them are directories only, though. Are
> tmpfiles.d supposed to create directories in /var too? Docs mention
> using tmpfiles.d to init /tmp or /run, not /var t
On Mon, Sep 15, 2014 at 12:53:40AM +0200, Nowaker wrote:
> Good point. I just did `pacman -Ql |grep -F ' /var'` to see how many
> files there are. 99.7% of them are directories only, though. Are
> tmpfiles.d supposed to create directories in /var too? Docs mention
> using tmpfiles.d to init /tmp or
Thanks Tobias,
I think I understand it. I've got a few questions:
1. Where is your data stored? /home? Or is it stored remotely?
2. How about downtimes? Do you do something about it, or just don't need
HA? If you do, do you keep a different VM running before your new VM
starts? (Then I guess you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>> At this point /var/lib/pacman/local defines the current state of
>> /usr. It's not "variable" - you write to /var/lib/pacman/local if
>> and only if you write to /usr. The description of /usr on wiki
>> perfectly describes why /var/lib/pacman/local
Hi Nowaker,
I am the one with the images, not Yamakaky:-)
On Sun, Sep 14, 2014 at 11:15 PM, Nowaker wrote:
> What are these significant changes more than just the pacman database
> that would make users go through trouble? In #41863 I see three parts:
>
> - move /var/lib/pacman/local/ to /usr
>
On Sun, Sep 14, 2014 at 11:15:13PM +0200, Nowaker wrote:
> At this point /var/lib/pacman/local defines the current state of /usr.
> It's not "variable" - you write to /var/lib/pacman/local if and only if
> you write to /usr. The description of /usr on wiki perfectly describes
> why /var/lib/pacman/
Hey guys,
I'm developing VirtKick (www.virtkick.io) and the very first supported
hypervisor will be Arch Linux. "Factory reset" feature would really fit
my use case.
> There's really no sense in the Arch devs and all Arch users go through
> the trouble, from what I can see. You're asking everyone
On Mon, Sep 15, 2014 at 1:59 AM, tlux wrote:
> Thank you for your constructive reply.
Is this sarcasm? I do think beta software can be destructive, though.
On Mon, Sep 15, 2014 at 1:38 AM, Manolo Martínez
wrote:
> From the manual (which I did read prior to asking):
>
> "When ncmpcpp starts, it tries to read user's keybindings from
> ~/.ncmpcpp/keys file. If no user's keybindings is found, ncmpcpp uses
Ah, you use ~/.ncmpcpp/bindings instead no
On 15/09, lolilolicon wrote:
> On Mon, Sep 15, 2014 at 12:14 AM, tlux wrote:
> > - the key bindings functionality has been redesign so as to use a bindings
> > file located at /usr/share/doc/ncmpcpp which may be copied to your
> > $XDG_CONFIG_HOME directory and then amended to suit your
Thanks a lot for the info!
> - the play, stop, pause, toggle, etc... command line arguments has
> been removed on purpose. See [1]. The workaround I am using now is to
> install mpc [2] and use it in all my scripts that was using the related
> ncmpcpp's command line argument
>
>
On 09/15/14 at 12:34am, lolilolicon wrote:
> On Mon, Sep 15, 2014 at 12:14 AM, tlux wrote:
> > - the key bindings functionality has been redesign so as to use a bindings
> > file located at /usr/share/doc/ncmpcpp which may be copied to your
> > $XDG_CONFIG_HOME directory and then amended
On Sun, 2014-09-14 at 19:23 +0200, Yamakaky wrote:
> Le 14/09/2014 19:17, Yamakaky a écrit :
> >> With factory reset you always know how to undo your own changes,
> >> getting back to the default state. That works for either all
> >> changes ever done to the system (factory reset) or selectively by
Le 14/09/2014 19:17, Yamakaky a écrit :
With factory reset you always know how to undo your own changes,
getting back to the default state. That works for either all
changes ever done to the system (factory reset) or selectively by
just removing the configuration files you tweaked last.
With de
With factory reset you always know how to undo your own changes,
getting back to the default state. That works for either all
changes ever done to the system (factory reset) or selectively by
just removing the configuration files you tweaked last.
Woh, I didn't thought about it, it's pretty cool
On Mon, Sep 15, 2014 at 12:14 AM, tlux wrote:
> - the key bindings functionality has been redesign so as to use a bindings
> file located at /usr/share/doc/ncmpcpp which may be copied to your
> $XDG_CONFIG_HOME directory and then amended to suit your needs.
Except ncmpcpp does not use X
On 14/09, Manolo Martínez wrote:
> Hi,
>
> Since the upgrade of nmcpcpp to 0.6beta2 yesterday, custom keybindings
> no longer work, and the commandline subcommands (most importantly for
> me, `ncmpcpp toggle`) have stopped working as well. Downgrading to
> 0.5.10 solve these issues.
>
> Perhaps
On 09/14, Tobias Hunger wrote:
>
> Factory reset is great, especially for a distro involving a lot of
> manual tweaking like arch:-)
> With factory reset you always know how to undo your own changes,
> getting back to the
> default state. That works for either all changes ever done to the
> system
> Moving the pacman DB is one step to make such a setup a bit more easy
> to create and It does
> not effect the traditional use case at all.
That's why I suggested putting it in a separate bugreport;
it gets accepted more easily, and then less change is needed for 41863.
On 14 September 2014 11:
Hi,
Since the upgrade of nmcpcpp to 0.6beta2 yesterday, custom keybindings
no longer work, and the commandline subcommands (most importantly for
me, `ncmpcpp toggle`) have stopped working as well. Downgrading to
0.5.10 solve these issues.
Perhaps the package should stay at the last stable releas
On Sat, Sep 13, 2014 at 7:12 PM, Leonid Isaev wrote:
> Yeah, that's what the 1st response in the bug report basically said: pacman DB
> location is a cosmetic detail.
No, it is not: /var will be wiped, so having the pacman DB there is
not a good idea.
> Also, note that systemd features like fact
23 matches
Mail list logo
