Re: [arch-general] pacman -Rnus inetutils

[Chris Billington via arch-general]

On Sun, Oct 25, 2020 at 11:58 AM Neven Sajko via arch-general <
arch-general@archlinux.org> wrote:

> Today pacman surprised me after updating my system: turns out nothing
> on my installation depended on inetutils any more, so I removed it,
> even though it was there forever. The following reboot proceeded fine.
>
> I'm curious if somebody knows which packages dropped it as a dependency
> lately.
>
> Regards,
> Neven
>

Likely xorg-xinit:

https://github.com/archlinux/svntogit-packages/commit/eea23f0e9c2244ee37656a953913181c7361dbb5#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a

Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)

[Chris Billington via arch-general]

I haven't seen this mentioned yet which makes me wonder if I've
misunderstood, but isn't it already the case that bash runs in a
posix-compatible mode if executed as /bin/sh?

I remember a bug a while back [1] that broke graphical login because
flatpak used a bashism in an X startup script. Does this not imply that any
bashisms executed with /bin/sh would already be causing breakage today on
Arch Linux?

[1] https://bugs.archlinux.org/task/61420#comment176360

Re: [arch-general] oops, 'sudo: pacman: command not found'

[Chris Billington via arch-general]

On Sun, 7 Jun 2020, 21:13 Greg Minshall,  wrote:

> i should mention that i seem to have the correct pacman "distribution"
> file:
> 
> bash apollo2 (master): {1198} ls -l /var/cache/pacman/pkg/pacman-5.2.1-*
> -rw-r--r-- 1 root root 856820 Apr 30 03:23
> /var/cache/pacman/pkg/pacman-5.2.1-5-x86_64.pkg.tar.zst
> -rw-r--r-- 1 root root 857872 May 23 03:04
> /var/cache/pacman/pkg/pacman-5.2.1-6-x86_64.pkg.tar.zst
> 
> (going through my symlink).  if that helps me patch back up my system?
>
> cheers, Greg
>

In terms of getting pacman, you might want to grab a precompiled
pacman-static from Eli Schwartz:

https://aur.archlinux.org/packages/pacman-static/#pinned-666894

-Chris

>

Re: [arch-general] nvidia-dkms pkgrel increase after every linux upgrade

[Chris Billington via arch-general]

On Tue, Mar 31, 2020 at 12:48 PM Amin Vakil  wrote:

>
> So why should nvidia-dkms upgrades?
>

it's because nvidia-dkms is part of a split package that builds both nvidia
and nvidia-dkms. The bump in pkgrel is to rebuild nvidia for the new
kernel, and as a consequence the pkgrel for nvidia-dkms is bumped too, even
though it is unnecessary.

-Chris

Re: [arch-general] latest kernel update surprise

[Chris Billington via arch-general]

 

On Sun, Mar 22, 2020 at 1:20 PM Ralf Mardorf via arch-general <
arch-general@archlinux.org> wrote:

> On Sun, 22 Mar 2020 14:43:44 +0100, Bennett Piater wrote:
> >However, maybe you should consider using the LTS kernel, packages as
> >linux- lts?
>
> It doesn't harm to install more than just one kernel and one of those
> kernels IMO should be a LTS kernel.
>

For those who are particularly concerned about breakage due to kernel
upgrades, they might be interested in my AUR packages for versioned kernel
installs:

https://aur.archlinux.org/pkgbase/linux-versioned-bin/
https://aur.archlinux.org/pkgbase/linux-lts-versioned-bin/

These repackage the Arch kernels so that multiple versions can be installed
simultaneously, so that after an upgrade the previous version is still
available.

Usually having the regular and LTS kernels is sufficient to ensure at least
one boots or doesn't have some regression that's appeared in the other, but
if you need more than that, versioned kernel installs might be useful.

-Chris

Re: [arch-general] post-install dependencies check

[Chris Billington via arch-general]

That looks like an unrelated bug in a hook installed by pacaudit. You
should report it here: https://github.com/steffenfritz/pacaudit

On Fri, Feb 21, 2020 at 3:52 PM Ralf Mardorf via arch-general <
arch-general@archlinux.org> wrote:

> On Fri, 2020-02-21 at 14:29 -0500, Eli Schwartz via arch-general wrote:
> > paccheck --opt-depends --quiet --recursive
>
> Thank you for the pointer :), it does the job.
>
> Btw. when installing it there was an issue:
>
> [rocketmouse@archlinux ~]$ sudo pacman -S pacutils
> [snip]
> (1/1) pacaudit-pre.hook
> 2020/02/21 21:46:45 invalid character 'I' looking for beginning of value
> error: command failed to execute correctly
> [snip]
>

Re: [arch-general] python-tqdm updates

[Chris Billington via arch-general]

Thanks Felix!

Oh it's no trouble, I was just wondering what was up, and if it was some
automated tool misbehaving thought it might be useful to point out.

Thanks for your work!

-Chris

On Mon, Feb 17, 2020 at 12:12 PM Felix Yan 
wrote:

> On 2/18/20 1:06 AM, Chris Billington via arch-general wrote:
> > [community]/python-tqdm has updated 13 times in the last week, though the
> > upstream has not been releasing that rapidly - the new Arch packages
> > correspond to the last few months of releases.
> >
> > This process hasn't quite gotten it up to date yet, so I expect one more
> > update is on the way!
> >
> > Is there a reason for not just skipping right to the latest version, if
> > several intermediate versions were missed?
> >
> > If this is for testing (incremental updates are usually easier to test),
> > presumably it should occur in [testing].
> >
> > Or perhaps this is the behaviour of some automated tooling that is
> > detecting when a package is out of date, and a human hasn't noticed?
>
> Actually updating of tqdm was blocked for quite some time due to tests
> being broken (which turns out to be my fault that used a broken way to
> run it).
>
> I did intensionally slow down the update to examine and check
> changelogs, also run it for a while so this won't happen again. Sorry
> for the trouble caused and it should soon be up-to-date.
>
> --
> Regards,
> Felix Yan
>
>

[arch-general] python-tqdm updates

[Chris Billington via arch-general]

[community]/python-tqdm has updated 13 times in the last week, though the
upstream has not been releasing that rapidly - the new Arch packages
correspond to the last few months of releases.

This process hasn't quite gotten it up to date yet, so I expect one more
update is on the way!

Is there a reason for not just skipping right to the latest version, if
several intermediate versions were missed?

If this is for testing (incremental updates are usually easier to test),
presumably it should occur in [testing].

Or perhaps this is the behaviour of some automated tooling that is
detecting when a package is out of date, and a human hasn't noticed?

This isn't important, I'm just curious.

-Chris

Re: [arch-general] how to upgrade 2017 server ?

[Chris Billington via arch-general]

Pacman static will likely help, but you'll need to actually install it and
use it, i.e.:

sudo pacman -S pacman-static
sudo pacman-static -Syu

On Sat, Jan 11, 2020 at 1:57 PM Shadrock Uhuru via arch-general <
arch-general@archlinux.org> wrote:

> i have a server that has not been booted since 2017,
> i tried upgrading with pacman -Syu,
> i have post the screen output at http://paste.openstack.org/show/788264/
> i thought adding Eli Schwartz' personal repository to  pacman.conf
> would have allowed the upgrade with his Binary builds of pacman-static.
> is my problem still to do with the xz to zstd change or something
> different ?
>
> shadrock
>

Re: [arch-general] python-cmake?

[Chris Billington via arch-general]

Though in this case OP is in a venv, so that's fine, it's only at the
system level where it's a bad idea.

Having said that, I do use pip outside of venvs a little bit, it can be
done somewhat safely, but you have to know what you're doing, such as
installing everything to /usr/local so it doesn't collide with
pacman-managed files and can be just deleted if you run into any issues:

$ cat /usr/lib/python3.8/site-packages/sitecustomize.py
import site
from sys import version_info as v
# Add /usr/local/lib/pythonx.y/site-packages as a site dir:
site.addsitedir('/usr/local/lib/python{}.{}/site-packages'.format(v.major,
v.minor))

$ sudo cat /root/.config/pip/pip.conf
[install]
install-option=--prefix=/usr/local

Main remaining issue is that unmet dependencies pulled in by pip might be
unnecessary if they are available in the Arch repos or AUR - though since
/usr/local/lib/pythonx.y/site-packages is added at the end of sys.path,
those packages won't shadow /usr/lib/pythonx.y/site-packages - they will
just be redundant and at worst break the pip-installed packages who
expected a different version and get the pacman-managed one instead.

-Chris

On Thu, Nov 28, 2019 at 1:50 PM Dmitry Yershov via arch-general <
arch-general@archlinux.org> wrote:

> For those who don't know, command
> $ sudo pip install 
> opens DOOM's gate. [
>
> https://open.spotify.com/track/2UKgx2oba7CltHLACr3xdT?si=1XKkDJXZTDK2N-M-W-8hQA
> ]
>
> It's not a good idea to do that if you don't want to destroy your package
> integrity.
>
> On Thu, Nov 28, 2019 at 1:32 PM Iyán Méndez Veiga  wrote:
>
> > El jueves, 28 de noviembre de 2019 17:26:28 (CET) usted escribió:
> > > In such cases I just use pip to install package at system level
> (without
> > > venv). If something gets packaged later I just do pip uninstall and
> > install
> > > arch package instead.
> > >
> > >Regards,
> > >Łukasz
> >
> > If you do that, pip will overwrite /usr/bin/cmake, right? Besides, I
> don't
> > want just to install it in my system, but write a PKGBUILD and probably
> > share
> > it in AUR.
> >
> > Thanks,
> > Iyán
> >
>

Re: [arch-general] Fedora Speeds Up Python 3.

[Chris Billington via arch-general]

Oh I remember why I didn't override libpython functions with LD_PRELOAD.
Python is statically linked to libpython in Ubuntu, which I was using at
the time, so it didn't work. Fedora decided not to go that far, but yeah,
Ubuntu has already taken that plunge.

If LD_PRELOADing libpython doesn't work in Ubuntu, then there probably
aren't many projects using it.




On Tue, Nov 26, 2019 at 9:31 AM Chris Billington 
wrote:

> Ah, that's interesting.
>
> I thought that would break my GIL profiling project that uses LD_PRELOAD
> (shameless plug: https://github.com/chrisjbillington/gil_load), but since
> I think I'm only overriding libc functions, it should be fine.
>
> I'm sure there are other things it will break (I could have overridden
> libpython functions instead - I wonder why I didn't, it seems simpler but
> there was probably a reason), but if someone wants to use code that hacks
> on the interpreter itself, having to install a custom python to do so is
> not so unreasonable. Those speedups are nothing to scoff at.
>
> -Chris
>
>
>
>
> On Tue, Nov 26, 2019 at 5:07 AM Ralph Corderoy 
> wrote:
>
>> Hi,
>>
>> I thought this might be of interest.
>>
>> https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
>>
>> By building with -fno-semantic-interposition they remove the PLT that
>> provides a level of indirection when calling a libpython function.
>> libpython often calls itself and the PLT adds L1-cache pressure plus
>> prevents inlining.  Gives gains of 25% on some workloads.
>>
>> --
>> Cheers, Ralph.
>>
>

Re: [arch-general] Fedora Speeds Up Python 3.

[Chris Billington via arch-general]

Ah, that's interesting.

I thought that would break my GIL profiling project that uses LD_PRELOAD
(shameless plug: https://github.com/chrisjbillington/gil_load), but since I
think I'm only overriding libc functions, it should be fine.

I'm sure there are other things it will break (I could have overridden
libpython functions instead - I wonder why I didn't, it seems simpler but
there was probably a reason), but if someone wants to use code that hacks
on the interpreter itself, having to install a custom python to do so is
not so unreasonable. Those speedups are nothing to scoff at.

-Chris




On Tue, Nov 26, 2019 at 5:07 AM Ralph Corderoy 
wrote:

> Hi,
>
> I thought this might be of interest.
> https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
>
> By building with -fno-semantic-interposition they remove the PLT that
> provides a level of indirection when calling a libpython function.
> libpython often calls itself and the PLT adds L1-cache pressure plus
> prevents inlining.  Gives gains of 25% on some workloads.
>
> --
> Cheers, Ralph.
>

Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?

[Chris Billington via arch-general]

You can use multiboot usb to set up multiple distro live images on one usb
drive:

https://aur.archlinux.org/packages/multibootusb/

I've used it, it works well. Looks like there's a build issue at the
moment, but in general it works :p

On Tue., 5 Nov. 2019, 22:50 Hongyi Zhao via arch-general, <
arch-general@archlinux.org> wrote:

> brent s.  于2019年11月6日周三 上午10:42写道：
> >
> > On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
> > >>> $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2
> > >> The ISO contains multiple partitions, so probably not.
> > >
> > > Why when using the whole usb disk, the problem will disappear?
> > >
> >
> > As both Eli and I have both explained, because if you use the whole disk
> > you're writing a partition table as *the partition table for the
> > device*. If you try to write to a partition, you end up with nested
> > partition tables. The .iso file is a *disk image*, not a *partition
> image*.
> >
> > >> Why are you
> > >> trying to do this, precisely?
> > >
> > > I want to use a usb disk for installation of multiple distros, say,
> > > Debian, Ubuntu, Arch, and so on.
> > > In this case, I must not using the whole usb disk for only one iso,
> > > and on the other hand, using whole usb disk for only one iso, is
> > > wasting of the usb's space, considering that we cannot use it for
> > > doing other things.  Furthermore, I noticed that the dd-based method
> > > is more robust than using the iso directly with grub's loopback
> > > module.
> >
> > In what way? I do not agree with this. It's far easier to update the
> > ISO, it's far easier to add new distributions to the bootloader (and
> > both updating and adding new entries can even be done by regular users
> > without granting disk reformatting permissions), etc. with grub loopback.
> >
> > > To say the least, for the Debian iso, the dd-based method can do the
> > > trick while the loopback method will fail to detect the cd-rom during
> > > the installation progress.
> >
> > Are you using the appropriate kernel cmdline args in the menu entry?
> > They're different from Arch's grub loopback menu entry.
>
> This is just what I stucked on.  I failed to figure out the correct
> cmdline args used for linux and initrd.
>
> >
> > https://wiki.debian.org/DebianLive/MultibootISO
>
> Useless.  This is for Debian *live* instead of Debian *install* iso,
> the image I use for install Debian is:
>
>
> http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd64-DVD-1.iso
>
>
>
> >
> > >
> > >>
> > >> Alternatively, you can use grub to boot an ISO *file* as a loopback
> > >> device. Some people do this to create multiboot USBs.
> > >
> > > As I said above, this method is not so robust as the dd-based method.
> > >  In detail, the most robust method for using  the usb disk to
> > > installation a unix/linux OS, should be the dd-based method which
> > > using the whole usb disk.  But this method has the shortcoming that it
> > > will occupy the whole usb disk with only a small iso image and
> > > prohibit us for using the usb disk to do other things at the same
> > > time.
> >
> > This seems highly subjective. What makes using DD superior to a
> > loopback? It occupies the same exact disk space as if you dd'd to a
> > partition except requires no modifications to the host disk.
> >
> > Now, if you *really* want to save space, you'd extract the squashed
> > filesystems/initrds/kernels from each ISO you want to add and create
> > grub entries that boot those directly, but that only affords you a
> > couple extra megabytes per distribution. However, *that is not what grub
> > loopback is*. Grub boots an iso file *directly*, with no modifications
> > required. I guarantee it's far more maintainable and robust than any use
> > of dd.
> >
> > --
> > brent saner
> > https://square-r00t.net/
> > GPG info: https://square-r00t.net/gpg-info
> >
>
>
> --
> Hongsheng Zhao 
> Institute of Semiconductors, Chinese Academy of Sciences
> GnuPG DSA: 0xD108493
>

Re: [arch-general] Bios Raid (Fake Raid) and Virtual Raid (Software Raid)

[Chris Billington via arch-general]

You can do software raid in Arch using mdadm. Details here:

https://wiki.archlinux.org/index.php/RAID

On Mon., 2 Sep. 2019, 09:07 Kelly Rogers via arch-general, <
arch-general@archlinux.org> wrote:

> Hi,
> Can you tell me what is capable to do Arch Linux: Bios Raid (Fake Raid) and
> Virtual Raid (Software Raid)?
> Thank you!
>

Re: [arch-general] Opening a document with unicode in path

[Chris Billington via arch-general]

> However, you might be onto something here because, interestingly enough:
> while BASH prompt and autocompletition feature both decode the character
> correctly, `ls` does not and outputs a sequence of escape codes:
>

That's interesting. If I run:

touch Proc$'\303\251'dures

and then ls, I get it printing correctly with the accented character. Then
if I do an os.listdir(b'.') in Python and look at its raw bytes, they are
the same as if I type the character on my keyboard (US keyboard but with a
compose key) and encode UTF8. So it looks to me to be UTF8 encoded (I do
not understand the escape sequences \303\251 - once in Python I see the two
bytes \xc3\xa9 for the character, which is the correct UTF8 encoding but do
not map to the numbers in the bash escape sequences).

What happens if you run the following?

$ echo $'\303\251'

I get the character printing correctly. This could be terminal-dependent
behaviour, it works for me in xterm, tilix, alacritty and gnome-terminal.
Perhaps if it doesn't work for you in one of these terminals it indicates
there is a locale issue deeper than the check you already did to ensure the
locale was set correctly.

On Fri, Aug 2, 2019 at 1:36 PM John Z.  wrote:

> > Can you determine some steps that exactly reproduce the problem?
> > Assuming that the problem should manifest when opening the file using
> > /usr/bin/loffice /path/to/file, I tried creating a test file and opening
> > it, and it worked:
>
> Hi Eli,
> good idea, I tried following your sequence as well.
>
> I created a directory using `mkdir`, then launched libre office and
> tried to save a file in it. Interesting thing happens:, it actually
> creates a directory named 'Proc?dures' instead of the original
> 'Procédures' directory, and saves it in there. I repeated the test
> twice, because the first time around, I was puzzled enough that I
> wasn't sure I actually saved the file.
>
> Furthermore, I copied the file using console into the 'Procédures',
> then opened it using libreoffice, and it opened the one in
> 'Proc?dures' - I know because I updated the file and saved it, and
> the latter one was updated.
>
> The only difference between us is that I'm using `libreoffice`
> launcher command, and you seem to have `loffice`? The package is
> also libreoffice-fresh, package version 6.2.5-1, and `libreoffice
> --version` 6.2.5.2 2@(build: 2)
> The --version in ubuntu, that works, is 6.0.7.3
>
>
> P.S. I am unsure how well Unicode fares in mailing lists, so I
> apologize if there are weird escape sequences in there. I just
> composed it with vim.
>
> --
> "That gum you like is going to come back in style."
>

Re: [arch-general] Opening a document with unicode in path

[Chris Billington via arch-general]

Could you verify that the encoding of the filepath is, in fact, UTF8?
Filepaths in linux are free to be arbitrary bytes despite the locale
settings. Most tools don't care, though I would expect the filepath to
display incorrectly in the terminal and file browser if it were not UTF8.
So it is probably a long shot but perhaps worth checking.

The following Python script, run in the directory containing the
file/directory containing the french character should tell you if it it
valid UTF8:

import os
for item in os.listdir(b'.'):
try:
item.decode('utf8')
except UnicodeDecodeError:
print(item, "is not valid UTF8")
raise

On Fri, Aug 2, 2019 at 12:48 PM Eli Schwartz via arch-general <
arch-general@archlinux.org> wrote:

> On 8/2/19 8:59 AM, John Z. wrote:
> > Hi everyone,
> > there's a document on Dropbox, that has unicode character in its
> > path (french character). Trying to open this document with libre
> > office (Plasma is running) fails with 'file not found', and the path
> > shown with error clearly presents the path with that unicode
> > character replaced by '??'
> >
> > What I tried:
> > * copy the document in a path where there's no unicode - it opens
> > * copy the document using shell - it works
> > * copy the document using Dolphin (from Plasma) - it works
> > * check $LANG - its set to `en_CA.UTF8`
> > * search for 'libreoffice unicode path', 'archlinux unicode path'
> >   and plethora of similar search terms - not much came through
> >
> > This makes me think the issue is actually with LibreOffice, but the
> > reason I ask here, and not in their forum, is that on another
> > computer running Ubuntu - this works without fail, so I'm fairly
> > certain the issue is in some local configuration.
> >
> > Could anyone shed some light on this, please, or at least point me
> > in some direction where I could look?
>
> Can you determine some steps that exactly reproduce the problem?
> Assuming that the problem should manifest when opening the file using
> /usr/bin/loffice /path/to/file, I tried creating a test file and opening
> it, and it worked:
>
> $ mkdir -p '/tmp/unicode paths are /'
> $ touch '/tmp/unicode paths are /testfile.txt'
> $ loffice '/tmp/unicode paths are /testfile.txt'
> $
>
> I could successfully edit this file in libreoffice, save content, or
> reopen it.
> Tested with LANG=en_US.UTF-8 and the libreoffice-fresh package
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

The output of the script command can contain all sorts of control
characters and ANSI escape sequences since it is exactly what is being
written to the terminal.

Incidentally, I have written a Python function for cleaning up such output
(solely used to document my Arch linux installation):

https://bitbucket.org/cbillington/arch_install/src/default/arch_install.py#lines-58

It doesn't just remove the control characters (and ANSI escape sequences),
it processes backspace characters and carriage returns etc to result in
what you would have seen on your screen. It is not comprehensive but does a
pretty good job. So you might want to postprocess your logs with that or
similar.

-Chris


On Fri, Mar 1, 2019 at 3:41 PM Maykel Franco  wrote:

> El vie., 1 mar. 2019 a las 21:32, Chris Billington
> () escribió:
> >
> > The 'flush' option could help with that:
> > [bilbo:~]$ script -h | grep flush
> >  -f, --flush   run flush after each write
> >
> > So, something like
> >
> > script -f -c '/usr/local/bin/cccam -d' mylogfile.log
> >
> > I would want to get to the bottom of why this binary does not play well
> with normal tools, but if you just need things working, it looks like you
> might have something workable with 'script'.
> >
> > -Chris
> >
> > On Fri, Mar 1, 2019 at 3:27 PM Maykel Franco 
> wrote:
> >>
> >> El vie., 1 mar. 2019 a las 20:08, Chris Billington
> >> () escribió:
> >> >
> >> > This is pretty strange.
> >> >
> >> > As for the script command, it can be passed the command to run, but I
> am guessing it will have the same symptoms as with 'unbuffer':
> >> >
> >> > [bilbo:~]$ script -c 'echo hello' mylogfile.log
> >> > Script started, file is mylogfile.log
> >> > hello
> >> > Script done, file is mylogfile.log
> >> > [bilbo:~]$ cat mylogfile.log
> >> > Script started on 2019-03-01 14:05:28-05:00 [TERM="xterm-256color"
> TTY="/dev/pts/0" COLUMNS="137" LINES="24"]
> >> > hello
> >> >
> >> > Script done on 2019-03-01 14:05:28-05:00 [COMMAND_EXIT_CODE="0"]
> >> >
> >> > On Fri, Mar 1, 2019 at 1:40 PM Maykel Franco via arch-general <
> arch-general@archlinux.org> wrote:
> >> >>
> >> >> El vie., 1 mar. 2019 a las 19:30, Ralph Corderoy
> >> >> () escribió:
> >> >> >
> >> >> > Hi Maykel,
> >> >> >
> >> >> > > > command &> out
> >> >> > >
> >> >> > > Not works... I probe all combinations:
> >> >> > >
> >> >> > > > file redirects stdout to file
> >> >> > > 1> file redirects stdout to file
> >> >> > > 2> file redirects stderr to file
> >> >> > > &> file redirects stdout and stderr to file
> >> >> >
> >> >> > Can you show us one complete command with `&>' in case there's
> something
> >> >> > else wrong?
> >> >> >
> >> >> > Otherwise, `LC_ALL=C strace -ff -o st /usr/local/bin/CCcam -d'
> >> >> > will capture the write(2)s or similar and you can see what file
> >> >> > descriptors its writing to and work backwards to see how that was
> >> >> > obtained, e.g. by opening /dev/tty.
> >> >> >
> >> >> > --
> >> >> > Cheers, Ralph.
> >> >>
> >> >> Nothing happens, it closes and the process does not start
> >> >>
> >> >> root@arch:~# LC_ALL=C strace -ff -o st /usr/local/bin/cccam -d
> >> >> root@arch:~#
> >> >> root@arch:~#
> >>
> >> ok, ask you for command script, ok:
> >>
> >> script -c '/usr/local/bin/cccam -d' mylogfile.log
> >>
> >> This is works, but only write to file when stop script with ctrl + c
> >>
> >>
> >> ~# cat mylogfile.log
> >> Script started on Fri Mar  1 21:24:35 2019
> >> 21:24:35.913 CCcam:
> >> ==
> >> 21:24:35.913 CCcam: starting CCcam 2.1.3 compiled on Nov 14 2009@00
> :47:12
> >> 21:24:35.913 CCcam:
> >> ==
> >> 21:24:35.913 CCcam: online using nodeId 95ced5a4a066a2b2
> >> 21:24:35.931 CCcam: create 1 cam device(s)
> >> 21:24:35.935 CCcam: readKeyfile: cannot open /var/keys/SoftCam.Key or
> not found
> >> 21:24:35.936 CCcam: readKeyfile: cannot open /var/keys/AutoRoll.Key or
> not found
> >> 21:24:35.936 CCcam: static cw not found or bad
> >> 21:24:35.943 CCcam: parsed 11522 entries from /var/etc/CCcam.prio
> >> 21:24:35.943 CCcam: added 1005 provider names from
> /var/etc/CCcam.providers
> >> 21:24:36.035 CCcam: added 11097 channel names from
> /var/etc/CCcam.channelinfo
> >> 21:24:36.035 CCcam: server started on port 47015
> >>
> >>
> >> The script download from:
> >>
> >> https://github.com/ryanfox1985/docker-cccam/blob/master/CCcam.x86_64
> >>
> >> Thanks.
>
> wow, it works! Many thanks.
>
> Now only remove ^M character from log files in buffer time but this not
> working:
>
>
> script -f -c '/usr/local/bin/cccam -d' mylogfile.log | sed 's/^M//g'
>
> If you want to try it because it does not work with the normal tools
> you can download it here
>
> https://github.com/ryanfox1985/docker-cccam/blob/master/CCcam.x86_64
>
> Many thanks again for all.
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

The 'flush' option could help with that:
[bilbo:~]$ script -h | grep flush
 -f, --flush   run flush after each write

So, something like

script -f -c '/usr/local/bin/cccam -d' mylogfile.log

I would want to get to the bottom of why this binary does not play well
with normal tools, but if you just need things working, it looks like you
might have something workable with 'script'.

-Chris

On Fri, Mar 1, 2019 at 3:27 PM Maykel Franco  wrote:

> El vie., 1 mar. 2019 a las 20:08, Chris Billington
> () escribió:
> >
> > This is pretty strange.
> >
> > As for the script command, it can be passed the command to run, but I am
> guessing it will have the same symptoms as with 'unbuffer':
> >
> > [bilbo:~]$ script -c 'echo hello' mylogfile.log
> > Script started, file is mylogfile.log
> > hello
> > Script done, file is mylogfile.log
> > [bilbo:~]$ cat mylogfile.log
> > Script started on 2019-03-01 14:05:28-05:00 [TERM="xterm-256color"
> TTY="/dev/pts/0" COLUMNS="137" LINES="24"]
> > hello
> >
> > Script done on 2019-03-01 14:05:28-05:00 [COMMAND_EXIT_CODE="0"]
> >
> > On Fri, Mar 1, 2019 at 1:40 PM Maykel Franco via arch-general <
> arch-general@archlinux.org> wrote:
> >>
> >> El vie., 1 mar. 2019 a las 19:30, Ralph Corderoy
> >> () escribió:
> >> >
> >> > Hi Maykel,
> >> >
> >> > > > command &> out
> >> > >
> >> > > Not works... I probe all combinations:
> >> > >
> >> > > > file redirects stdout to file
> >> > > 1> file redirects stdout to file
> >> > > 2> file redirects stderr to file
> >> > > &> file redirects stdout and stderr to file
> >> >
> >> > Can you show us one complete command with `&>' in case there's
> something
> >> > else wrong?
> >> >
> >> > Otherwise, `LC_ALL=C strace -ff -o st /usr/local/bin/CCcam -d'
> >> > will capture the write(2)s or similar and you can see what file
> >> > descriptors its writing to and work backwards to see how that was
> >> > obtained, e.g. by opening /dev/tty.
> >> >
> >> > --
> >> > Cheers, Ralph.
> >>
> >> Nothing happens, it closes and the process does not start
> >>
> >> root@arch:~# LC_ALL=C strace -ff -o st /usr/local/bin/cccam -d
> >> root@arch:~#
> >> root@arch:~#
>
> ok, ask you for command script, ok:
>
> script -c '/usr/local/bin/cccam -d' mylogfile.log
>
> This is works, but only write to file when stop script with ctrl + c
>
>
> ~# cat mylogfile.log
> Script started on Fri Mar  1 21:24:35 2019
> 21:24:35.913 CCcam:
> ==
> 21:24:35.913 CCcam: starting CCcam 2.1.3 compiled on Nov 14 2009@00:47:12
> 21:24:35.913 CCcam:
> ==
> 21:24:35.913 CCcam: online using nodeId 95ced5a4a066a2b2
> 21:24:35.931 CCcam: create 1 cam device(s)
> 21:24:35.935 CCcam: readKeyfile: cannot open /var/keys/SoftCam.Key or not
> found
> 21:24:35.936 CCcam: readKeyfile: cannot open /var/keys/AutoRoll.Key or not
> found
> 21:24:35.936 CCcam: static cw not found or bad
> 21:24:35.943 CCcam: parsed 11522 entries from /var/etc/CCcam.prio
> 21:24:35.943 CCcam: added 1005 provider names from /var/etc/CCcam.providers
> 21:24:36.035 CCcam: added 11097 channel names from
> /var/etc/CCcam.channelinfo
> 21:24:36.035 CCcam: server started on port 47015
>
>
> The script download from:
>
> https://github.com/ryanfox1985/docker-cccam/blob/master/CCcam.x86_64
>
> Thanks.
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

This is pretty strange.

As for the script command, it can be passed the command to run, but I am
guessing it will have the same symptoms as with 'unbuffer':

[bilbo:~]$ script -c 'echo hello' mylogfile.log
Script started, file is mylogfile.log
hello
Script done, file is mylogfile.log
[bilbo:~]$ cat mylogfile.log
Script started on 2019-03-01 14:05:28-05:00 [TERM="xterm-256color"
TTY="/dev/pts/0" COLUMNS="137" LINES="24"]
hello

Script done on 2019-03-01 14:05:28-05:00 [COMMAND_EXIT_CODE="0"]

On Fri, Mar 1, 2019 at 1:40 PM Maykel Franco via arch-general <
arch-general@archlinux.org> wrote:

> El vie., 1 mar. 2019 a las 19:30, Ralph Corderoy
> () escribió:
> >
> > Hi Maykel,
> >
> > > > command &> out
> > >
> > > Not works... I probe all combinations:
> > >
> > > > file redirects stdout to file
> > > 1> file redirects stdout to file
> > > 2> file redirects stderr to file
> > > &> file redirects stdout and stderr to file
> >
> > Can you show us one complete command with `&>' in case there's something
> > else wrong?
> >
> > Otherwise, `LC_ALL=C strace -ff -o st /usr/local/bin/CCcam -d'
> > will capture the write(2)s or similar and you can see what file
> > descriptors its writing to and work backwards to see how that was
> > obtained, e.g. by opening /dev/tty.
> >
> > --
> > Cheers, Ralph.
>
> Nothing happens, it closes and the process does not start
>
> root@arch:~# LC_ALL=C strace -ff -o st /usr/local/bin/cccam -d
> root@arch:~#
> root@arch:~#
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

Perplexing! How about the 'script' command?

On Fri., 1 Mar. 2019, 13:13 Maykel Franco,  wrote:

> El vie., 1 mar. 2019 a las 19:09, Chris Billington
> () escribió:
> >
> > The program could also explicitly be modifying its behaviour based on
> whether stdout is a tty or not. You can trick it into thinking its stdout
> is a tty with the program 'unbuffer'. For example:
> >
> > [bilbo:~]$ python -c 'import sys; print(sys.stdout.isatty())' | cat
> > False
> > [bilbo:~]$ unbuffer python -c 'import sys; print(sys.stdout.isatty())' |
> cat
> > True
> >
> > So you might try:
> >
> > unbuffer /usr/local/bin/CCcam -d > file
> >
> >
> > On Fri, Mar 1, 2019 at 1:04 PM Maykel Franco 
> wrote:
> >>
> >> El vie., 1 mar. 2019 a las 19:01, Chris Billington
> >> () escribió:
> >> >
> >> > Perhaps the program writes its log to stderr, and not to stdout?
> >> >
> >> > If so, you can redirect both stdout and stderr to file with:
> >> >
> >> > command &> out
> >> >
> >> >
> >> >
> >> > On Fri, Mar 1, 2019 at 12:47 PM Maykel Franco via arch-general <
> arch-general@archlinux.org> wrote:
> >> >>
> >> >> HI, I playing with cccam for a proyect with decoder and I like stdout
> >> >> console log to specific log but not work...
> >> >>
> >> >> I try all:
> >> >>
> >> >> >> /var/log/test.log
> >> >>
> >> >> tee -a /var/log/test.log
> >> >>
> >> >> strace -p pid
> >> >>
> >> >> The command is:
> >> >>
> >> >> /usr/local/bin/CCcam -d
> >> >> 18:43:15.717 CCcam:
> >> >>
> ==
> >> >> 18:43:15.717 CCcam: starting CCcam
> >> >>
> ==
> >> >> 18:43:15.717 CCcam: online using nodeId 91dd747775a31f66
> >> >> 18:43:15.735 CCcam: create 1 cam device(s)
> >> >> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/SoftCam.Key
> or not found
> >> >> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/AutoRoll.Key
> or not found
> >> >> 18:43:15.739 CCcam: static cw not found or bad
> >> >> 18:43:15.746 CCcam: parsed 11522 entries from /var/etc/CCcam.prio
> >> >> 18:43:15.747 CCcam: added 1005 provider names from
> /var/etc/CCcam.providers
> >> >> 18:43:15.798 CCcam: added 11097 channel names from
> /var/etc/CCcam.channelinfo
> >> >> 18:43:15.798 CCcam: server started on port 47015
> >> >>
> >> >>
> >> >>
> >> >> The binary program is:
> >> >>
> >> >> /usr/local/bin/CCcam: ELF 64-bit LSB executable, x86-64, version 1
> >> >> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> >> >> for GNU/Linux 2.6.32, BuildID[sha1]=6ab44025c0a35a3
> >> >> 83d63f30e96e489f29df424b5, stripped
> >> >>
> >> >>
> >> >> I've tried everything, I do not know what to do to have that output
> >> >> write it to log.
> >> >>
> >> >> I've tried inclusy with tty, pts but it's impossible.
> >> >>
> >> >> Does somebody knows why it could be? with any other command /
> program works well
> >> >>
> >> >> with the only thing that I have managed to write to log is add:
> >> >>
> >> >> | stdbuf -oL
> >> >>
> >> >> but the program closes
> >>
> >> Thanks for your reply.
> >>
> >> Not works... I probe all combinations:
> >>
> >> > file redirects stdout to file
> >> 1> file redirects stdout to file
> >> 2> file redirects stderr to file
> >> &> file redirects stdout and stderr to file
> >>
> >> Not work...
>
> Unbuffer work but the program exit...
>
> $ unbuffer /usr/local/bin/cccam -d > /var/log/test.log
>
> tail: /var/log/test.log: file truncated
> 19:12:12.548 CCcam:
> ==
> 19:12:12.548 CCcam: starting CCcam 2.1.3 compiled on Nov 14 2009@00:47:12
> 19:12:12.548 CCcam:
> ==
> 19:12:12.548 CCcam: online using nodeId 95ced5a4a066a2b2
> 19:12:12.568 CCcam: create 1 cam device(s)
>
> and exit... crash/close program
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

The program could also explicitly be modifying its behaviour based on
whether stdout is a tty or not. You can trick it into thinking its stdout
is a tty with the program 'unbuffer'. For example:

[bilbo:~]$ python -c 'import sys; print(sys.stdout.isatty())' | cat
False
[bilbo:~]$ unbuffer python -c 'import sys; print(sys.stdout.isatty())' | cat
True

So you might try:

unbuffer /usr/local/bin/CCcam -d > file


On Fri, Mar 1, 2019 at 1:04 PM Maykel Franco  wrote:

> El vie., 1 mar. 2019 a las 19:01, Chris Billington
> () escribió:
> >
> > Perhaps the program writes its log to stderr, and not to stdout?
> >
> > If so, you can redirect both stdout and stderr to file with:
> >
> > command &> out
> >
> >
> >
> > On Fri, Mar 1, 2019 at 12:47 PM Maykel Franco via arch-general <
> arch-general@archlinux.org> wrote:
> >>
> >> HI, I playing with cccam for a proyect with decoder and I like stdout
> >> console log to specific log but not work...
> >>
> >> I try all:
> >>
> >> >> /var/log/test.log
> >>
> >> tee -a /var/log/test.log
> >>
> >> strace -p pid
> >>
> >> The command is:
> >>
> >> /usr/local/bin/CCcam -d
> >> 18:43:15.717 CCcam:
> >> ==
> >> 18:43:15.717 CCcam: starting CCcam
> >> ==
> >> 18:43:15.717 CCcam: online using nodeId 91dd747775a31f66
> >> 18:43:15.735 CCcam: create 1 cam device(s)
> >> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/SoftCam.Key or
> not found
> >> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/AutoRoll.Key or
> not found
> >> 18:43:15.739 CCcam: static cw not found or bad
> >> 18:43:15.746 CCcam: parsed 11522 entries from /var/etc/CCcam.prio
> >> 18:43:15.747 CCcam: added 1005 provider names from
> /var/etc/CCcam.providers
> >> 18:43:15.798 CCcam: added 11097 channel names from
> /var/etc/CCcam.channelinfo
> >> 18:43:15.798 CCcam: server started on port 47015
> >>
> >>
> >>
> >> The binary program is:
> >>
> >> /usr/local/bin/CCcam: ELF 64-bit LSB executable, x86-64, version 1
> >> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> >> for GNU/Linux 2.6.32, BuildID[sha1]=6ab44025c0a35a3
> >> 83d63f30e96e489f29df424b5, stripped
> >>
> >>
> >> I've tried everything, I do not know what to do to have that output
> >> write it to log.
> >>
> >> I've tried inclusy with tty, pts but it's impossible.
> >>
> >> Does somebody knows why it could be? with any other command / program
> works well
> >>
> >> with the only thing that I have managed to write to log is add:
> >>
> >> | stdbuf -oL
> >>
> >> but the program closes
>
> Thanks for your reply.
>
> Not works... I probe all combinations:
>
> > file redirects stdout to file
> 1> file redirects stdout to file
> 2> file redirects stderr to file
> &> file redirects stdout and stderr to file
>
> Not work...
>

Re: [arch-general] Impossible redirect console buffer to log

[Chris Billington via arch-general]

Perhaps the program writes its log to stderr, and not to stdout?

If so, you can redirect both stdout and stderr to file with:

command &> out



On Fri, Mar 1, 2019 at 12:47 PM Maykel Franco via arch-general <
arch-general@archlinux.org> wrote:

> HI, I playing with cccam for a proyect with decoder and I like stdout
> console log to specific log but not work...
>
> I try all:
>
> >> /var/log/test.log
>
> tee -a /var/log/test.log
>
> strace -p pid
>
> The command is:
>
> /usr/local/bin/CCcam -d
> 18:43:15.717 CCcam:
> ==
> 18:43:15.717 CCcam: starting CCcam
> ==
> 18:43:15.717 CCcam: online using nodeId 91dd747775a31f66
> 18:43:15.735 CCcam: create 1 cam device(s)
> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/SoftCam.Key or not
> found
> 18:43:15.739 CCcam: readKeyfile: cannot open /var/keys/AutoRoll.Key or not
> found
> 18:43:15.739 CCcam: static cw not found or bad
> 18:43:15.746 CCcam: parsed 11522 entries from /var/etc/CCcam.prio
> 18:43:15.747 CCcam: added 1005 provider names from /var/etc/CCcam.providers
> 18:43:15.798 CCcam: added 11097 channel names from
> /var/etc/CCcam.channelinfo
> 18:43:15.798 CCcam: server started on port 47015
>
>
>
> The binary program is:
>
> /usr/local/bin/CCcam: ELF 64-bit LSB executable, x86-64, version 1
> (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
> for GNU/Linux 2.6.32, BuildID[sha1]=6ab44025c0a35a3
> 83d63f30e96e489f29df424b5, stripped
>
>
> I've tried everything, I do not know what to do to have that output
> write it to log.
>
> I've tried inclusy with tty, pts but it's impossible.
>
> Does somebody knows why it could be? with any other command / program
> works well
>
> with the only thing that I have managed to write to log is add:
>
> | stdbuf -oL
>
> but the program closes
>