Re: [arch-general] ncmpcpp 0.6beta2-1
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 > > [1]:http://bugs.musicpd.org/view.php?id=4013 > [2]:https://www.archlinux.org/packages/?name=mpc I was hoping this was some kind of oversight... Well, too bad. I guess I'll have to start using another client, as you say. Cheers, Manolo pgpQbGldzkn_6.pgp Description: PGP signature
Re: [arch-general] ncmpcpp 0.6beta2-1
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 to suit your needs. > > Except ncmpcpp does not use XDG_CONFIG_HOME > > Anyway, everything one needs to know is in the man page and example > config files. RTFM is the best advice for OP. >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 its default keybindings. An example keybindings file containing all default values is provided with ncmpcpp and can be found usually in /usr/share/doc/ncmpcpp (exact location may depend on used distribution/OS/configure prefix)." This hasn't changed from earlier versions, or at least I do have a ~/.nmcpcpp/keys file, which was, and isn't, correctly read. Manolo
[arch-general] ncmpcpp 0.6beta2-1
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 release? (I should say I don't follow ncmpcpp development closely at all, and for all I know that beta might have been around for years. In any case, I'm seeing the above problems with the beta version.) Cheers, Manolo --
Re: [arch-general] Vim clipboard option
On 08/21/14 at 10:34am, Daniel Micay wrote: > The vim package only exists to avoid some dependencies. If it linked > against X libraries, there wouldn't be much point in having it. That makes sense. Thanks, Manolo pgpXyVkwr0fgJ.pgp Description: PGP signature
Re: [arch-general] Vim clipboard option
On 08/21/14 at 11:17am, Magnus Therning wrote: > On Thu, Aug 21, 2014 at 07:39:50AM +0200, Yamakaky wrote: > > Hi > > > > It's good to have a real vim package, but the `clipboard` option is now > > disabled (see `vim --version`). Is there any reason ? I use it a lot via the > > "+ register. > > It's disabled in the vim package, but enabled in gvim. Is there any > particular reason why you want the terminal-only vim to use the X > clipboard? In my case, I prefer the terminal-only vim, yet need to share information with, say, libreoffice from time to time. M pgphCbI2EOOTx.pgp Description: PGP signature
Re: [arch-general] Vim clipboard option
On 08/21/14 at 07:39am, Yamakaky wrote: > It's good to have a real vim package, but the `clipboard` option is now > disabled (see `vim --version`). Is there any reason ? I use it a lot via the > "+ register. I too find this disappointing. The only reason I have gvim installed is in order to use the "+ and "* registers. Manolo
Re: [arch-general] Skype and PA
> If you would still like to use Skype it is possible to set PulseAudio up as a > temporary pipe to ALSA [1]. > > [1] > https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_as_a_minimal_unintrusive_dumb_pipe_to_ALSA That's very useful. I wish I could convince my dad to switch to some other, less obnoxious piece of software, but that would take more time, I think. Thanks. M
Re: [arch-general] Skype and PA
On 06/23/14 at 04:57pm, Sebastiaan Lokhorst wrote: > It works (the application starts and you can chat), but anything related to > audio does not work. So when you are calling someone you can't hear them > and they can't hear you. That makes sense :) What a drag... Thanks, Manolo
[arch-general] Skype and PA
Hello, Pacman warns that Skype 4.3 only works with Pulseaudio. As far as I can tell, that is not true. I don't use PA, and Skype works. Manolo --
Re: [arch-general] creating an archlinux usb key with persistence
On 03/13/14 at 03:59am, Mark Lee wrote:
> While I don't know of any specific instructions on the Arch wiki, you can
> install Arch Linux onto a usb stick like a regular {H,S}DD. In my case, I
> made three partitions. The first was an NTFS partition for using the usb
> stick as a data transferring device; the second was a FAT32 boot partition
> (for EFI and Syslinux booting); the third was a BTRFS root partition (with
> transparent LZO compression enabled to reduce read/write). In addition, I
> use a script to place certain directories (mostly $HOME directories in my
> case) in a tmpfs partition (I just link them to /tmp) to decrease the
> effect of USB writes on the system. My script syncs the tmpfs directores to
> disk every 5 minutes. Since it's a full Arch Linux system, it upgrades and
> evolves like any other Arch system.
That sounds amazing, and I want one :) If you have a fuller blog post
somewhere, or that script is available, I'm interested.
Manolo
Re: [arch-general] Zsh, tmux, and paths
On 03/13/13 at 09:46pm, Ivan S. Freitas wrote: > On Wed, Mar 13, 2013 at 4:31 PM, Manolo Martínez > wrote: > > Hello, > > > > I've noticed that, if one modifies the PATH environment variable in > > .zshenv, tmux fails to notice this. That is, `echo $PATH` yields > > different results within and without tmux, with the former being the > > default path, and the latter the path as modified by .zshenv. > > > > When I update PATH in .zshrc, though, it is picked up fine by tmux. > > This should also happen when you log in a tty. > > > * First sources .zshenv > > * Then sources /etc/zsh/zprofile > > * Then .zshrc > > > > In the second step, /etc/zsh/zprofile sources /etc/profile, > > which changes the path back to the default. Might this be > > the reason why tmux picks .zshrc path changes up correctly, but not > > .zshenv path changes? > > It was reported [1] and documented in the wiki [2]. zprofile sources > /etc/profile, > which replaces your $PATH ignoring already existing settings. What I did was > modify /etc/profile to include the value of PATH in the newly created > variable: > PATH="$PATH:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin" > > [1] https://bugs.archlinux.org/task/31873 > [2] https://wiki.archlinux.org/index.php/Zsh#Configuration_files > I had read the wiki, but before my path woes, and failed to put two and two together. Thanks for the info. If I may ask, what's the rationale for overwriting the path? Cheers, Manolo
[arch-general] Zsh, tmux, and paths
Hello, I've noticed that, if one modifies the PATH environment variable in .zshenv, tmux fails to notice this. That is, `echo $PATH` yields different results within and without tmux, with the former being the default path, and the latter the path as modified by .zshenv. When I update PATH in .zshrc, though, it is picked up fine by tmux. I don't know what to make of this, but I've noticed the following, which might be related. If I undertand it correctly, zhs: * First sources .zshenv * Then sources /etc/zsh/zprofile * Then .zshrc In the second step, /etc/zsh/zprofile sources /etc/profile, which changes the path back to the default. Might this be the reason why tmux picks .zshrc path changes up correctly, but not .zshenv path changes? Cheers, Manolo --
[arch-general] Filesystem and /etc/shadow
Hello, The update to filesystem-2012.10-2 brings with it a new /etc/shadow. This is one of the cases in which inspecting the diff between what I have and the .pacnew doesn't give any insight (to clueless users such as me). Could anyone provide a summary of what we should change in our current /etc/shadow? Thanks, Manolo --
Re: [arch-general] ABS and pacman
Thanks everyone for the illuminating responses. IgnorePackage and IgnoreGroup seem to be what I need, after all. Cheers, Manolo On 09/26/12 at 09:10am, gt wrote: > On Tue, Sep 25, 2012 at 02:09:59PM -0400, Manolo Martínez wrote: > > Hello, > > > > I've just had a minor hiccup, because one of the packages updated in my > > pacman -Syu this morning substituted a version I had tweaked the ABS > > way. > > > > Nothing serious, as I say, and wholly my fault, but yet I was > > wondering: Would it be possible/make sense to have pacman inform us > > whenever it is going to > > substitute a package that has been ABS'd? > > I put my local packages under a group "custom_packages" and add > IgnoreGroup = custom_packages in pacman.conf > > Whenever there's an update available, pacman notifies me as others have > mentioned. > > Then I go to the arch git repo for the package, see the changes and > decide if i need to add those changes to my package. > > For example yesterday mutt was updated due to a bug, but since that bug > doesn't affect me, i didn't upgrade my custom mutt package. --
Re: [arch-general] ABS and pacman
On 09/25/12 at 08:16pm, Karol Blazewicz wrote: > On Tue, Sep 25, 2012 at 8:09 PM, Manolo Martínez > wrote: > > Would it be possible/make sense to have pacman inform us whenever it is > > going to > > substitute a package that has been ABS'd? > > Why not put your tweaked packages in 'IgnorePkg' in pacman.conf? Many times these tweaks are temporary and, indeed, newer versions make them unnecessary. It can definitely be done as you suggest, but I think it'd be in the spirit of the help provided by, e.g., .pacsave and .pacnew files, to have pacman issue a warning. --
[arch-general] ABS and pacman
Hello, I've just had a minor hiccup, because one of the packages updated in my pacman -Syu this morning substituted a version I had tweaked the ABS way. Nothing serious, as I say, and wholly my fault, but yet I was wondering: Would it be possible/make sense to have pacman inform us whenever it is going to substitute a package that has been ABS'd? Manolo --
Re: [arch-general] [OT] Sending a laptop to the repair shop
Thanks to everyone for the comments. Let me say, lest I'm taken to be even more clueless than I am, that I am aware that live CDs and alternative users are no real protection. They will probably work as a signal that I'd prefer my data not to be browsed, though, and that's enough for me, I think. M On 09/21/12 at 12:26am, Calvin Morrison wrote: > I just had my x220 repaired at a small place. I told them I used linux > exclusively and that I didn't want to give out my password. They understood > and everything went ok. > > Typically they just want your password to verify that everything works and > maybe to run a quick system cleanup which is very common. In my case I was > having part of the screen fixed and obviously did not need it. > > this is a good time to keep a small windows installation handy but empty > and just sent the grub default 2 windows when you are going to the shop > On Sep 20, 2012 9:55 PM, "Manolo Martínez" wrote: > > > On 09/20/12 at 10:46pm, Martín Cigorraga wrote: > > > On Thu, Sep 20, 2012 at 9:51 PM, Ralf Mardorf < > > ralf.mard...@alice-dsl.net>wrote: > > > > > > > On Thu, 2012-09-20 at 20:38 -0400, Manolo Martínez wrote: > > > > Do you create a new user for them, you > > > > > give them your user and password and hope for the best, ask them to > > use > > > > > a live CD? What? > > > > > > > > > > > WHAT? You can't be so naive dude, I would promptly give my life than my > > > pwd!!! Which reminds me: http://xkcd.com/538/ > > > > Yep, that's why I was asking. I think I'll just create another user for > > them. This will at least protect my files from casual browsing. Although > > Ralf's probably right they don't give a rat's ass. > > > > Manolo > > -- > > --
Re: [arch-general] [OT] Sending a laptop to the repair shop
On 09/20/12 at 10:46pm, Martín Cigorraga wrote: > On Thu, Sep 20, 2012 at 9:51 PM, Ralf Mardorf > wrote: > > > On Thu, 2012-09-20 at 20:38 -0400, Manolo Martínez wrote: > > Do you create a new user for them, you > > > give them your user and password and hope for the best, ask them to use > > > a live CD? What? > > > > > WHAT? You can't be so naive dude, I would promptly give my life than my > pwd!!! Which reminds me: http://xkcd.com/538/ Yep, that's why I was asking. I think I'll just create another user for them. This will at least protect my files from casual browsing. Although Ralf's probably right they don't give a rat's ass. Manolo --
[arch-general] [OT] Sending a laptop to the repair shop
Just a quick question. What do you guys do when you have to leave your laptop at the repair shop? Do you create a new user for them, you give them your user and password and hope for the best, ask them to use a live CD? What? Manolo --
Re: [arch-general] Polkit and systemd
On 08/15/12 at 12:25am, John K Pate wrote: > On Tue, 14 Aug 2012 19:13:33 -0400 > Manolo Martínez wrote: > > > Hello, > > > > If I'm not wrong, systemd makes consolekit superfluous. This is what I > > thought it took for polkit to work with systemd: > > > > * compile polkit with --enable-systemd > > * enable the systemd polkit service > > * that's it? > > > > But that's not it. Although polkit seems to work in console, it does not > > work in X. This is not terribly surprising, because I haven't done > > anything equivalent to launching my WM under "ck-launch-session", as I > > used to do with consolekit. Is there an equivalent way of launching the > > window manager under systemd-acting-as-consolekit? > > > > I should explain that I'm using no display manager, and I'd like to keep > > it this way, if at all possible. > > Do you start your window manager with startx? I start fluxbox that way, > and switching to: > > startx -- vt01 > > prevents a different virtual terminal from being started, and > everything works fine. > Yes, that's a nice workaround. Thanks John and Tom. Manolo
[arch-general] Polkit and systemd
Hello, If I'm not wrong, systemd makes consolekit superfluous. This is what I thought it took for polkit to work with systemd: * compile polkit with --enable-systemd * enable the systemd polkit service * that's it? But that's not it. Although polkit seems to work in console, it does not work in X. This is not terribly surprising, because I haven't done anything equivalent to launching my WM under "ck-launch-session", as I used to do with consolekit. Is there an equivalent way of launching the window manager under systemd-acting-as-consolekit? I should explain that I'm using no display manager, and I'd like to keep it this way, if at all possible. Cheers, Manolo --
Re: [arch-general] [arch-dev-public] syslinux 4.05-5 does not boot
On 08/09/12 at 06:26pm, Thomas Bächler wrote: > Am 09.08.2012 18:23, schrieb Manolo Martínez: > > On 08/09/12 at 11:18am, Leonid Isaev wrote: > >> On Thu, 9 Aug 2012 11:35:04 -0400 > >> Manolo Martínez wrote: > >>> Is it safe to change an existing /boot from ext2 to ext4? > >> > >> https://wiki.archlinux.org/index.php/Ext4 > >> > > Is the information on the move from ext3 to ext4 valid for the issue at > > hand? > > Yes. > Thanks, Thomas and Leonid. M --
Re: [arch-general] [arch-dev-public] syslinux 4.05-5 does not boot
On 08/09/12 at 11:18am, Leonid Isaev wrote: > On Thu, 9 Aug 2012 11:35:04 -0400 > Manolo Martínez wrote: > > Is it safe to change an existing /boot from ext2 to ext4? > > https://wiki.archlinux.org/index.php/Ext4 > Is the information on the move from ext3 to ext4 valid for the issue at hand? M
Re: [arch-general] [arch-dev-public] syslinux 4.05-5 does not boot
On 08/09/12 at 06:08pm, Thomas Bächler wrote: > Am 09.08.2012 17:58, schrieb Baho Utot: > > It is not 10 year old information it was published just after ext4 came out > > > > google is your friend. > > It is still outdated information. After ext4 came out, it took a few > months until Google started implementing ext4 without a journal - > precisely because ext2 was outdated and had bad performance. This work > has been finished long ago and is available to everyone. > > It seems Google is _your_ friend. > ... and another enthralling battle of wits brought to you by arch-general! --
Re: [arch-general] [arch-dev-public] syslinux 4.05-5 does not boot
On 08/09/12 at 05:27pm, Thomas Bächler wrote: > Am 09.08.2012 17:12, schrieb Jonathan: > > In the past I have seen ext2 saves time during boot vs ext3.Having a > > journal is no use since the files are rarely changed and the > > filesystem is mostly opened read only. The journal takes up some > > space. These may matter to you if you are trying to optimize boot > > times or disk usage. > > Then use ext4 without a journal. ext2 is out of date and ext4 is > superior in every aspect. > > Is it safe to change an existing /boot from ext2 to ext4? Manolo --
Re: [arch-general] My end-user $0.02 on /etc/rc.conf splitting.
On 07/25/12 at 01:47am, C Anthony Risinger wrote: > to reiterate the above ... it works fantastic. the Pandaboard runs 9 > custom unit files (1/2 of which are just mods to the shipped unit > files): > > u.dhcpd4.service > u.dnsmasq.service > u.fwknopd.service > u.hostapd.service > iptables.service > u.net.dhcp@.service > u.net.static@.service > u.openvpn.service (writing now :-) > u.services.target > What does u.net.static@.service do? If something similar to ifplugd, I'm interested :) Manolo
Re: [arch-general] rc.local.shutdown equivalent in systemd
On 07/24/12 at 12:44pm, Tom Gundersen wrote: > On Tue, Jul 24, 2012 at 12:38 PM, Rodrigo Rivas > wrote: > > On Tue, Jul 24, 2012 at 4:31 AM, James Nelson wrote: > > > >> On 07/23/12 20:10, Manolo Martínez wrote: > >> > > [Unit] > >> Description=Unload module before shutdown > >> Before=shutdown.target > >> > >> [Service] > >> Type=oneshot > >> ExecStart=/usr/bin/rmmod modulename > >> > >> [Install] > >> WantedBy=multi-user.target > >> > >> Haven't tried it, might not work, no guarantees, etc.. > >> > > > > Shouldn't it be just > > > > [Unit] > > Description=Unload module before shutdown > > > > [Service] > > Type=oneshot > > ExecStart=/usr/bin/rmmod modulename > > > > [Install] > > WantedBy=shutdown.target > > > > Without multi-user.target or Before=? > > Better put Before= if it is important that the module is properly > removed before the machine is shut down. > Thanks. I need to read a lot more about systemd, it seems. > Btw, you should probably file a bug against whatever module requires this... There is. It's the one linked to and described in [this forum thread](https://bbs.archlinux.org/viewtopic.php?id=113985). It's been closed as solved, but yesterday I had a couple of faulty shutdowns, reminiscent of the ones I used to have before removing ehci_hcd, so I don't know. Manolo --
[arch-general] rc.local.shutdown equivalent in systemd
Hello, I've decided to try systemd and see for myself. Anyway, I need to remove a module before shutdown, which rc.local.shutdown did nicely for me. I know there is an initscripts-systemd packages that would allow me to keep using rc.local.shutdown, but the wiki discourages its use and recommends instead using systemd native configuration files. Hence my question: what's the systemd native way to do stuff (in my case, remove a module) before shutdown? Thanks, Manolo --
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 10:45pm, Tom Gundersen wrote: > On Fri, Jul 20, 2012 at 9:37 PM, Manolo Martínez > wrote: > > On 07/20/12 at 09:31pm, Florian Pritz wrote: > >> On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez > >> wrote: > >> > On 07/20/12 at 02:56pm, Daniel Wallace wrote: > >> > > All of those changes were discussed by the devs on arch-dev-public > >> > > >> > I, for one, thought that running archlinux responsibly only committed me > >> > to subscribing to and reading arch-announce and -general. If I need to > >> > read -dev-public too I will, but it'd be good to be explicit about this. > >> > >> You don't have to read arch-dev-public if you just want to use Arch, but > >> your original question was about the reasoning behind the move and that > >> information is available in the mailing list archives. > > > > No, apparently you do need to know why and how these things are done even > > if you just > > want to use Arch and don't plan to develop for it. That's a lesson I learnt > > around here anyway. > > The aim is that reading the news items should be enough to deal with > any update. If you want notifications in advance of future plans or if > you want to understand the reasoning behind certain changes, then > following arch-dev-public should be enough. arch-general is typically > for user discussions, and not so much for development discussions. > OK. I'll subscribe to arch-dev-public, then. I think it would be good if the "mailing lists" page at archlinux.org explained what one is to expect from each mailing list, and maybe recommend which mailing lists to follow, like you just did. Thanks, Manolo
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 09:31pm, Florian Pritz wrote: > On Fri, 20 Jul 2012 15:15:47 -0400 Manolo Martínez > wrote: > > On 07/20/12 at 02:56pm, Daniel Wallace wrote: > > > All of those changes were discussed by the devs on arch-dev-public > > > > I, for one, thought that running archlinux responsibly only committed me > > to subscribing to and reading arch-announce and -general. If I need to > > read -dev-public too I will, but it'd be good to be explicit about this. > > You don't have to read arch-dev-public if you just want to use Arch, but > your original question was about the reasoning behind the move and that > information is available in the mailing list archives. No, apparently you do need to know why and how these things are done even if you just want to use Arch and don't plan to develop for it. That's a lesson I learnt around here anyway. Manolo
Re: [arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 02:56pm, Daniel Wallace wrote: > All of those changes were discussed by the devs on arch-dev-public > > filesystem -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023014.html > > grub -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-June/023147.html > > /lib -> usr/lib -> > http://mailman.archlinux.org/pipermail/arch-dev-public/2012-March/022625.html > > There are also discussions there about what will happen and when stuff > breaks like the pacman bug when usr lib was in testing, most of that > happens that I, for one, thought that running archlinux responsibly only committed me to subscribing to and reading arch-announce and -general. If I need to read -dev-public too I will, but it'd be good to be explicit about this. In my previous e-mail I also raised the point of having a roadmap for upgrades that require user intervention. I'd like to know if that'd be feasible; I think it would be useful. Manolo --
[arch-general] Roadmap for user-intervention upgrades [was: Still Glibc problems]
On 07/20/12 at 03:27pm, Norbert Zeh wrote: > I > think the reason why you are having a much more serious issue is that it seems > you haven't updated your system in a long time. So now you're running into > dealing with two slightly tricky upgrades (filesystem + glibc) at the same > time. I've had no problems with filesystem, /lib -> /usr/lib or, today, grub -> grub2. I have at best a tenuous grasp of the issues involved in these three changes, so I can only consider myself very lucky that I'm not in the quandary others seem to be. I know, though, of enthusiastic archers who have resented the problems that have resulted from some of these changes, and feel less enthusiastic about archlinux now. I guess there is an inherent tension between the rolling-distro concept and KISS: if you want an up-to-date system you are bound to change things that work (which is hardly KISS). I was wondering if the following could be useful to minimize the impact of these, more trepidant pacman -Syu's: archlinux could publish a roadmap of user-intervention upgrades well in advance: we will do this in Q1, that in Q2, and that other thing in Q3. This way users could, for example, plan their upgrades so as not to have to deal with two such problematic migrations at the same time. It would also be nice to know a bit more of the rationale behind the moves. I'm sure that they are all for the best, and I trust arch decision-makers (and one can find out more about the changes by reading blogs and forum discussions), but still it'd be good to have a small FAQ posted to arch-general before each of the biggish moves. Manolo
Re: [arch-general] Nvidia/vesafb/GRUB2
On 06/26/12 at 09:19pm, Kevin Chadwick wrote: > If it wasn't huge before then you were either running nouveau or vesa > framebuffer on the console and Nvidia in the desktop. This warning is > likely due to the fact that running a framebuffer and Nvidia used to > crash linux. It can probably? be ignored now. FWIW, the latest nVidia have broken my (and many others') suspend, forcing me to vga=0 and very low console resolution. So things are noticeably worse as of late. M
Re: [arch-general] Campaign against Secure Boot
On 06/26/12 at 12:55am, Karol Babioch wrote: > I have only the following criticism: Given the relatively low cost of > getting a signed certificate from Microsoft (to my knowledge it will > cost about 100 USD), it might fail to achieve what it is proposed to. > Obviously Microsoft will try to prevent any sort of abuse, but even if > Microsoft only hands out signed certificates after some extensive checks > to trustworthy companies/organisations, it can't control it from there > on any more. Just for clarification: you seem to be endorsing a model in which organizations (linux distros?) pay Microsoft for the right to install non-Microsoft software in PCs. Is that correct? Manolo
Re: [arch-general] Campaign against Secure Boot
On 06/25/12 at 05:59pm, Ralf Mardorf wrote: > We > already know, that UEFI can't be disabled for every hardware :(. That's what I thought, too. Also: the point is not just whether there are technical ways around Secure Boot, but whether this will raise the technical entry barrier to FOSS, making it unacceptably cumbersome to many. I hope everyone agrees that this would be bad news. Manolo
[arch-general] Campaign against Secure Boot
Is Arch going to sign [this petition](http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement)? I, for one humble user, would like it (us, whatever) to. Manolo --
Re: [arch-general] [Offtopic] back up /var/log before shutdown
> On Wed, Jun 20, 2012 at 14:38:27 +0530, gt wrote: > For the mutt users, just press "#" to decouple the message from the parent > thread. :-) Not in my .muttrc. What option is this? I might have unbound the key for some reason :) > > Manolo
Re: [arch-general] Source control on /etc
On 06/20/12 at 09:28am, Squall Lionheart wrote: > Your welcome. I will post a message to everyone when I roll out my next > version since it's a huge improvement over the current one with a lot of > very powerful and user friendly features, as well as efficiency > improvements. > It'd be nice if you added it to the AUR. M
[arch-general] Lyx (was Re: Reliable documents (was Re: RFC: OpenRC as init system for Arch))
On 04/30/12 at 09:16pm, Rashif Ray Rahman wrote: > On 30 April 2012 17:35, Lorenzo Bandieri wrote: > > > 2012/4/30 Kevin Chadwick : > > > On Mon, 30 Apr 2012 11:30:23 +0200 > > > Gour wrote: > > > > > >> we did embrace LaTeX/LyX etc. > > > > > > To get the benefit of your experience. Do you use Lyx as your editor or > > > something else. > > > > Sorry if I "jump in", but as a LaTeX user I usually suggest to stay > > away from Lyx. Basically it's an editor that attempt to make LaTeX > > work like Words, which IMHO it's not the best approach. I suggest to > > use an editor that doesn't try to hide how LaTeX works, and one of my > > favourite is TexMaker. > > > > There is nothing wrong in using LyX. I don't know why you have that > perception. It helps when your writing is qualitative rather than > quantitative (in which case LaTeX and a more involved process can be > adopted). LyX is the only qt (or gtk) program I use in a regular basis, and the main reason why I type xinit at all -- another reason being that elinks sometimes does not make sense of webpages. Manolo
Re: [arch-general] dmenu 4.5
On 04/17/12 at 05:17pm, Karol Blazewicz wrote: > 2012/4/17 Bartłomiej Piotrowski : > > On 04/17/2012 05:13 PM, Karol Blazewicz wrote: > >> On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez > >> wrote: > >>> After updating dmenu to 4.5 yesterday, it does not honour my choices of > >>> font > >>> and size. I haven't had the time to look into it yet, just wanted to give > >>> the > >>> heads up. > >> > >> dmenu 4.5-2 uses the xft patch > >> https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5 > > > > And it will be reverted to the end of the week. > > If so, please write a note about the issues either in git or in the > bugtracker https://bugs.archlinux.org/task/28370 Sorry, I thought I understood that the patch would be reverted? M--
Re: [arch-general] dmenu 4.5
On 04/17/12 at 05:14pm, Bartłomiej Piotrowski wrote: > On 04/17/2012 05:13 PM, Karol Blazewicz wrote: > > On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez > > wrote: > >> After updating dmenu to 4.5 yesterday, it does not honour my choices of > >> font > >> and size. I haven't had the time to look into it yet, just wanted to give > >> the > >> heads up. > > > > dmenu 4.5-2 uses the xft patch > > https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5 > > And it will be reverted to the end of the week. > > -- > Bartłomiej Piotrowski > Arch Linux Trusted User > http://archlinux.org/ Thanks Karol and Bartlomiej for the info. I'll wait, then. Manolo --
[arch-general] dmenu 4.5
Hi, After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up. Cheers, Manolo
Re: [arch-general] usb disk not visible
On 04/09/12 at 06:04pm, Andrea Crotti wrote: > I have a problem with an external USB disk here, which is a WD 500Gb > bought last year. > > Recently I decided finally to format it to ext3, since I'm using Linux > everywhere, but now I don't seem to see it from my dell latitude. > > On my mini dell everything works perfectly, but on the latitude I get > only this from dmesg > > [ 8916.825474] usb 2-1.2: USB disconnect, device number 11 > [ 8917.013895] usb 2-1.2: new high-speed USB device number 12 using ehci_hcd > [ 8919.126604] usb 2-1.2: USB disconnect, device number 12 > [ 8919.314274] usb 2-1.2: new high-speed USB device number 13 using ehci_hcd > > and fdisk doesn't detect anything: > [andrea@dell]$ sudo fdisk -l /dev/sdb > > Any idea of what it could be? udisks --enumerate shows it? I'm sure you have looked into it, but any chance that it's in, say, /dev/sdc?
Re: [arch-general] plugins for zathura
On 03/13/12 at 07:43pm, Keits wrote: > On 11:08 Tue 13 Mar , Jarek Sedlacek wrote: > > The following package are in the AUR: > > > > zathura-djvu-git zathura-girara-git zathura-pdf-mupdf-git > > zathura-pdf-poppler-git zathura-ps-git > > > > Installing those should let it view most files. > > zathura without plugins is just bunch of useless bytes. > These plugins should be in ``community'' repo too. Not only that. the AUR plugins force the installation of the AUR version of zathura -- or so it has seemed to me after resurfacing from dependency hell. Manolo --
Re: [arch-general] DST in New York
On 03/11/12 at 02:09pm, Taylor Hedberg wrote: > Manolo Martínez, Sun 2012-03-11 @ 14:00:32-0400: > > I see, thank you. I've just moved from hwclock to ntpd and it is > > sinchronising correctly. Are you using hwclock? > > I'm using ntpd. If your time skew occurred when using the hwclock daemon > without NTP, then my guess would be that your motherboard battery is > dead/dying so the hardware RTC is losing time. I don't know, I turn off my laptop regularly, and I never see (significant) skew. Also, the time this moring was incorrect by 20 hours, I would have noticed if my CMOS was *that* dead. Manolo --
Re: [arch-general] DST in New York
On 03/11/12 at 12:01pm, Taylor Hedberg wrote: > Manolo Martínez, Mon 2012-03-12 @ 05:52:51-0400: > > Hi, this morning we had DST kick in in New York. When I woke up (8:30) > > the clock showed 4:30. I have > > > > HARDWARECLOCK="UTC" > > TIMEZONE="America/New_York" > > > > in rc.conf. I've since changed the time manually, but wanted to give > > the heads up, in case there is somethng somwehere that needs fixing. > > I'm in the same time zone and my clock updated without any problems. Not > that that helps you at all, but I don't think it's a problem with the > tzdata or anything. I see, thank you. I've just moved from hwclock to ntpd and it is sinchronising correctly. Are you using hwclock? Manolo --
Re: [arch-general] DST in New York
On 03/11/12 at 01:19pm, Taylor Hedberg wrote: > Martin Zecher, Sun 2012-03-11 @ 12:35:58-0400: > > Do you use systemd? > > No, just initscripts. Same here --
[arch-general] DST in New York
Hi, this morning we had DST kick in in New York. When I woke up (8:30) the clock showed 4:30. I have HARDWARECLOCK="UTC" TIMEZONE="America/New_York" in rc.conf. I've since changed the time manually, but wanted to give the heads up, in case there is somethng somwehere that needs fixing. Cheers, Manolo
Re: [arch-general] Gringotts, alternatives?
On 03/02/12 at 10:00am, Taylor Hedberg wrote: > If all you need to store securely are text files, and you are a Vim > user, you can use Vim's built-in Blowfish encryption support. > > :set cryptmethod=blowfish > > Then use the :X command to set a key and encrypt the current buffer. I didn't know about that. That's interesting, thanks. --
Re: [arch-general] [solved] netcfg pppoe 'error sending pppoe packet: Network is down'
On 12/10/11 at 12:31pm, Ralf Mardorf wrote: > today I've got some time for my Arch Linux. Thomas, your hint does the job. > Parallel to your reply I found > ifconfig eth0 up > netcfg pppoe > which does job too. > Just curious: I thought that netcfg raised eth0 itself? M
Re: [arch-general] ACPI bug in kernel 3.1?
On 11/20/11 at 11:35pm, Carlchristian Eckert wrote: > >If plain pm-suspend works fine, this means that the lid close event is > >triggered twice: on close and open. You can verify whether it is true by > >replacing pm-suspend with logger "Some message" in handler.sh and see if > >there > >are two messages in /var/log/messages. > > > > > Yes, I get actually exactly this behaviour since the last update. > Two messages and sleep is obviously triggered twice (manual > pm-suspend works fine) Same here... --
Re: [arch-general] Vim with X
On 11/17/11 at 09:08pm, Bastien Dejean wrote: > Manolo Martínez a écrit : > > > As it is now, the standalone vim cannot copy to and from the X clipboard. > > I wrote the following functions to circumvent the problem: That is a very nice idea. Thanks for the suggestion. It'd be interesting to know how many vim arch users resort to this or other neat tricks to communicate with the X clipboard. Manolo
Re: [arch-general] Vim with X
On 11/16/11 at 07:09pm, Ray Rashif wrote: > Since recently, I've been using my own build of vim. I realised I > could do with some convenience after all these years and set up > omni-completion with supertab context for python. If you build in > python3 interpreter the completion does not work, so I have to rebuild > with only python2. I tried enabling X while I was at it but the > yanking to clipboard did not work as far as KDE's Klipper is > concerned. I use pathogen so updating vim or any of its plugins is not > a concern, and thus have vim ignored in pacman. > > You can do the same. > Yep, I'll give that a try. Thanks for the suggestion! M
Re: [arch-general] Vim with X
On 11/16/11 at 08:44am, Jason Melton wrote: > On Tue, Nov 15, 2011 at 11:00 PM, Manolo Martínez > wrote: > > don't want gvim, but we find copying and pasting to and from the clipboard > > useful. > > > > If you install gvim, you can still run "vim" in an emulator and you get > the compile flags that gvim used. Which, relevant to this question include > "+xterm_clipboard". gvim is not "gvim only, it's gvim AND vim. > > You can then "set clipboard=unnamedplus" (or just "unnamed", or not at > all, depending on your preference) and go to town. Yes, I know. But gvim pulls in ruby and lua (does that even make sense? I swear that's what pacman asks to do), and that's a bit too much for clipboard support. I was assuming (unwarrantedly, it appears) that my profile of use of vim (in a terminal emulator, but relying on the x clipboard) was fairly standard. I stand corrected now. Manolo --
Re: [arch-general] Vim with X
On 11/15/11 at 05:46pm, Taylor Hedberg wrote: > John K Pate, Tue 2011-11-15 @ 22:09:57+: > > ctrl-ins, shift-ins, middle-click should all still work. At least they > > do for me, and I don't have gvim installed. Or do I have something > > else installed that makes them work? > > He was probably referring to Vim's ability to yank text into its * and + > registers, which represent the X11 primary selection and clipboard, > respectively, using commands like "+yy. This doesn't work unless you > have installed gVim. Yes, sorry, that's what I meant. M --
Re: [arch-general] Vim with X
On 11/15/11 at 11:57pm, Ray Rashif wrote: > On 15 November 2011 22:00, Manolo Martínez wrote: > The policy had already been revised when the split was made to have > vim and gvim. Vim had to become lightweight as many people were > complaining about its bulk. > > Thanks for the explanation, Ray. I guess I should learn to make do without copying among X programs, as those people doubtlessly do. Manolo
Re: [arch-general] Vim with X
On 11/15/11 at 03:09pm, Jelle van der Waa wrote: > >Any chance that the policy on compile flags to use for vim could be revised? > > > >Thanks > >Manolo > > > You could search the archives, why this happend, else just use ABS. > Thanks for your reply, Jelle. I am using ABS atm. I (or rather a certain prominent search engine) couldn't find any thread related to this topic in the archives. Do you happen to remember about when was it covered in the list? Thanks Manolo > -- > Jelle van der Waa --
[arch-general] Vim with X
Hello everyone, As it is now, the standalone vim cannot copy to and from the X clipboard. For a vim that does this, one needs to install gvim, which pulls a number of dependencies that you don't really need if you don't use the GUI. I guess the rationale for this is that people using vim in console have no use for X support, and the rest will be happy to use gvim. But I think many people -- at any rate, I'm one of them -- use vim in a terminal emulator in X. We don't want gvim, but we find copying and pasting to and from the clipboard useful. Any chance that the policy on compile flags to use for vim could be revised? Thanks Manolo --
Re: [arch-general] Monitoring changes to [core], [extra], [community]
On 10/28/11 at 01:46am, Bernardo Barros wrote: > Or even better, write a haskell program to p0arse the data and to that =)) Sorry, yes. Haskell script, of course :) --
Re: [arch-general] Monitoring changes to [core], [extra], [community]
On 10/28/11 at 10:36am, Magnus Therning wrote: > monitor. The ideal solution would allow me to get a notification > whenever a package that requires ghc to build is updated, but that's > probably a bit much to hope for :) > Couldn't you just write a little python script that parses the packages feed and matches the title of the entry to a list of your 50 packages? I do that to extract the torrents of tv shows I watch out of the eztv feed :) Manolo
Re: [arch-general] coping with damaging updates
On 10/27/11 at 12:25pm, Leonid Isaev wrote: > On (10/27/11 18:48), Manolo Martínez wrote: > -~> On 10/27/11 at 11:24am, Leonid Isaev wrote: > -~> > you should let console-kit do the permission granting. In fact, on a > modern > -~> > linux system you only have to be a member of 1 group: users. > -~> > -~> And wheel? > > Wheel has to done manually, of course. What *kit does, in a nutshell, is just > elevate priviledges of local users over remote, so you can have control over > devices attached to your machine. > -- Should this be added to the Beginners' Guide at the wiki? I'm thinking of something ecumenical along the lines of "do it the usergroup way, or you may consider adding yourself to users and wheel and allow *kit to take care of the rest by launching your wm under a *kit-session. Manolo --
Re: [arch-general] coping with damaging updates
On 10/27/11 at 11:24am, Leonid Isaev wrote: > you should let console-kit do the permission granting. In fact, on a modern > linux system you only have to be a member of 1 group: users. And wheel?
Re: [arch-general] update
On 10/11/11 at 11:39am, Vitor Eiji Justus Sakaguti wrote: > On Mon, Oct 10, 2011 at 9:41 PM, Martin wrote: > > [spanish] Carlos, probablemente la demora con pacman no tenga nada que ver > > con gnome. Lo más probable es que tu mirror esté funcionando lento. Prueba > > esto: https://wiki.archlinux.org/index.php/Reflector > > > > En todo caso, esta lista de correo es en inglés, por lo que intenta escribir > > siempre en ese idioma. [/spanish] > > It says: > Carlos, pacman being slow probably has nothing to do with gnome. It is > more likely that your mirror is slow. Try this: > https://wiki.archlinux.org/index.php/Reflector > > Anyway, this mail list is in English, why do you always try to write > in this language? In fact, the last sentence should be translated rather as: This mailing list is in English, so please try to stick to this language. I don't think this is very important, and I'm a recent subscriber to the list anyway, but I believe that short exchanges in other languages such as this (in which a person who obviously does not write English asks a question, and then an answer is given in his or her language, together with a friendly reminder about the language of the list) are harmless. Manolo --
Re: [arch-general] wvdial and ppp configuration
On 09/10/11 at 04:27pm, Fons Adriaensen wrote: > Since my (unknown) neighbour finally got smart enough to > lock me out of his wireless access point (still unencrypted, > probably filters on MAC address now)- Or maybe he was just being a good neighbour and got tired of having his bandwidth abused :)
Re: [arch-general] Down doesn't stick
I use arch + openbox and I don't. M On 09/02/11 at 09:16pm, Jorge Almeida wrote: > On Fri, Sep 2, 2011 at 8:41 PM, Patrick Burroughs > wrote: > > On Fri, Sep 2, 2011 at 12:26, Jorge Almeida wrote: > >> Good point. In a TTY there is no problem. It's an X thing. Maybe I > >> should try the openbox list. Google shows nothing. > > > > You might try `xset r 116` — that will explicitly enable autorepeat > > for the Down key, if it was somehow disabled. > > > Right. It does the job. I guess I'll put it in the openbox startup > file. Somehow it seems strange that openbox is responsable for this, I > would first suspect some driver or something like that. It would be > interesting to know whether somebody else who uses arch+openbox has > this problem. > > Thanks > > Jorge --
Re: [arch-general] Weird behaviour A/C vs battery
Hello, thanks everyone for your help, and the very interesting suggestions. I'm afraid my problem was more mundane. It appears to be an effect of the interaction of some modules with the latest kernels. In my case, it can be bypassed by rmmodding ehci_hcd at shutdown. More information, links to bug reports, etc. here: https://bbs.archlinux.org/viewtopic.php?id=113985 Cheers, Manolo On 08/14/11 at 01:15am, XeCycle wrote: > Richard Schütz writes: > > [...] > > > Switching between reboot methods is possible with a kernel > > parameter. There are several methods. May the source [0] be with > > you. > > > > [0] > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-3.0.y.git;a=blob;f=arch/x86/kernel/reboot.c;h=9242436e9937e5a4ef91c6baa04eaf2e90243125;hb=HEAD#l55 > > Hi, your answer seems to be the point. However I believe he should > change the halt method --- he doesn't want to reboot. > > -- > Carl Lei (XeCycle) > Department of Physics, Shanghai Jiao Tong University > OpenPGP public key: 7795E591 > Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591 --
Re: [arch-general] Weird behaviour A/C vs battery
Hi, Carl, thanks. In my case any of these commands, when on battery, brings the computer to an unresponsive state -- I wish it would reboot! Anyway, as I say, I was hoping that a difference of behaviour between A/C and battery would be indicative of malfunction in some particular piece of software... Maybe if you end up looking into your user's system you'll be kind enough to let me know what you find? Thanks again, Manolo > Hello, I'm a board master of "GNULinux" board on my school BBS. Today > one guy reported a similar issue, but he's using Ubuntu 11.04. He said > when he runs `poweroff`, `init 0`, or `shutdown -h now` with only > battery on, after some normal steps, it shows "will now halt" on the > terminal, and the system reboots. > > Hope it'll help. > > -- > Carl Lei (XeCycle) > Department of Physics, Shanghai Jiao Tong University > OpenPGP public key: 7795E591 > Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591 --
Re: [arch-general] Weird behaviour A/C vs battery
Thanks a lot for your reply. In this laptop (a Toshiba Satellite U500, btw) I've had several versions of Ubuntu and Fedora installed, and Windows 7 -- although it's currently Arch-only. I've only had this behaviour in Arch. Manolo On 08/09/2011 06:30 PM, Madhurya Kakati wrote: On Tue, Aug 9, 2011 at 12:03 PM, Manolo Martínez wrote: Hello everyone, I would like to ask you for help with a weird piece of behaviour of my arch box (now 3.0, but it was the same with older kernels): * Shutdown works OK when on A/C, but, when on battery, the computer ends up with fans on and the On button light on. In this state it is totally unresponsive -- it looks much as it does when it fails to suspend. * But, on battery (and A/C too), it reboots perfectly well. So I've resorted to rebooting when I want to shutdown on battery, and then plugging it off once it gets to the bios screen. I'm sure these will be tell-tale symptoms to more enlightened arch users. For my part, I am totally clueless. I would have suspected an acpid problem, but I have no shutdown event or action enabled. I don't see anything interesting in the logs either. Any piece of advise will be very welcome. Cheers, Manolo Have you tried to see if this occurs with any other linux distro? Try something like Linux Mint or ubuntu. If you can, then see if this problem occurs in Windows too.
[arch-general] Weird behaviour A/C vs battery
Hello everyone, I would like to ask you for help with a weird piece of behaviour of my arch box (now 3.0, but it was the same with older kernels): * Shutdown works OK when on A/C, but, when on battery, the computer ends up with fans on and the On button light on. In this state it is totally unresponsive -- it looks much as it does when it fails to suspend. * But, on battery (and A/C too), it reboots perfectly well. So I've resorted to rebooting when I want to shutdown on battery, and then plugging it off once it gets to the bios screen. I'm sure these will be tell-tale symptoms to more enlightened arch users. For my part, I am totally clueless. I would have suspected an acpid problem, but I have no shutdown event or action enabled. I don't see anything interesting in the logs either. Any piece of advise will be very welcome. Cheers, Manolo
