Re: [arch-general] New kernel/updates - Is the timezone information messed up for dual-boot configs?

[pascal]

Le Tue, 22 Sep 2009 20:29:03 +0200,
Alessandro Doro  a écrit :

> On Tue, Sep 22, 2009 at 01:17:55PM -0500, David C. Rankin wrote:
> > Listmates,
> > 
> > I have been chasing my tail on the madwifi issue and I
> > think I have found the problem. It's not madwifi at all, it's the
> > timezone handling.
> > 
> > My box is dual-boot, Arch - Vista. Accordingly, the
> > hardware clock is set to localtime:
> > 
> > LOCALE="en_US.utf8"
> > HARDWARECLOCK="local"
> 
> Recent changes:
> HARDWARECLOCK="localtime"
> 

You might also want to check the /var/lib/hwclock/adjtime file and
remove it if it's "adjusting" too much.

Re: [arch-general] xmonad and java environment

[pascal]

Le Fri, 25 Sep 2009 16:34:57 -0600
Sergey Manucharian  a écrit:

> Hi all,
> 
> I've installed openproj from AUR and met the following issue: the
> program runs, but the main GUI window is blank (no buttons, menus -
> nothing), although the dialog windows appear normal. I don't have much
> experience with java, and tried both jre and openjdk6 - with
> the same result. Then I tried to run openproj without any window
> manager, and it worked! I noticed that openjdk6 warns:
>   when you use a non-reparenting window manager
>   set _JAVA_AWT_WM_NONREPARENTING=1 in /etc/profile.d/openjdk6.sh
> So the setting of that env. variable indeed helps with openjdk6, but
> not with jre.
> 
> Any advices?
> 
> Thanks,
> Sergey
> 

Setting up a startup hook with startupHook = setWMName "LG3D" should help, see
http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Problems_with_Java_applications.2C_Applet_java_console

Re: [arch-general] having a problem from upgraded vim again (version 266)

[pascal]

Le Sun, 04 Oct 2009 18:06:57 +0800
b4283  a écrit:

> I'm having these errors even when i start vim with no parameters, are 
> anyone seeing the same?
> 
> $ LC_ALL=POSIX LANG=POSIX vim
> 
> E486: Pattern not found: <\s*\([ap]\|img\)\s*$
> E486: Pattern not found: <\s*a\s[^>]*>[^<]*$
> search hit BOTTOM, continuing at TOPError detected while processing 
> /usr/share/vim/vimfiles/plugin/unhtml.vim
> line   34:
> E486: Pattern not found: 

Re: [arch-general] X fails to start with intel card after latestkernel update

[pascal]

Le Thu, 15 Oct 2009 11:48:44 +0200
Rafa Griman  a écrit:

> Hi :)
> 
> On Wednesday 14 October 2009 21:35:58 David C. Rankin wrote:
> > On Monday 12 October 2009 02:51:51 pm Dusty wrote:
> > > Hey guys,
> > >
> > > I have managed to upgrade (pacman -Syu) grabbing the new kernel upgrade
> > > and not killing my X using KMS.
> > >
> > > What I did to avoid the problems you guys are getting is the following:
> > >
> > > 1) Goto the ArchWiki and search for intel and bring up the following
> > > page:
> > >
> > > http://wiki.archlinux.org/index.php/Intel_Graphics
> > >
> > > 2) Follow the steps for the KMS settings..
> > >
> > > 3) Then run pacman -Syu and grab the updates, install them.
> > >
> > > 4) Reboot.
> > >
> > > 5) It works :)
> > >
> > > I have the following hardware:
> > 
> > 
> > 
> > > Primary display adapter: #9
> > > root ~  #
> > >
> > > I suspect, if you were to follow the KMS steps in the above URL, then
> > >  reboot you will probably be ok.  If that doesn't work, I would roll
> > > back, do the KMS steps, then upgrade (grab the new kernel) and reboot..
> > >
> > > Hope this helps you guys,
> > >
> > > Let me know how you get on.
> > >
> > > Kind Regards,
> > >
> > > Dusty.
> > 
> > 
> > 
> > Dusty, Glad you got it working, but for me:
> > 
> > Bummer :-(
> > 
> > I have followed the wiki to a T, using 'Late' Start, but my intel box is
> >  still dead in the water:
> 
> 
> I'm using the "Early" start on an MSI Wind and works perfect.
> 
> 
> > Last login: Tue Oct 13 10:44:44 2009 from alchemy.3111skyline.com
> > 14:24 supersff:~> cat /etc/modprobe.d/modprobe.conf
> > #
> > # /etc/modprobe.d/modprobe.conf (for v2.6 kernels)
> > #
> > options i915 modeset=1
> > 14:25 supersff:~> grep i915 /etc/rc.conf
> > MODULES=(tg3 acx intel_agp i915)
> > 
> > I have updated everything, and I still get the black screen of death. On
> >  boot, you can tell that X tries to start, the screen flashes, but then BAM
> >  back to the terminal screen. Latest logs:
> 
> 
> How about booting into runlevel 3 and then manualy running "startx"? Have you 
> tried that?
> 
> 
> > http://www.3111skyline.com/download/Archlinux/bugs/supersff/Xorg.0.log.1014
> 
> 
> Been looking through your log and see this line:
> 
>   Kernel command line: root=/dev/sda6 ro vga=0x31a
> 
> Shouldn't you remove all the vga= and/or video= options in menu.lst?
> 
> Maybe that's the problem.
> 
> HTH
> 
>Rafa
> 

Hi
In the last Xorg.0.log I can see that you removed the "vga=0x31a" part. But
the vesa module is still loaded (and unloaded short after) just after the intel
module, and the output used is VGA1. I also have an 915 chipset (though a
915GM) and upgraded to Xorg from testing to see if I could reproduce your
problem. Apart some serious performance regression (and some freezes...) it
works almost fine. I diff'ed my Xorg.0.log with yours and I don't have the
vesa module loaded. Also my output is set to LVDS1, which I remember changed
when I went to KMS some months ago (before that the output was VGA1, if I
record correctly). I also have a line saying " (**) intel(0): Kernel mode
setting active, disabling FBC. ", which doesn't appear in your log. Makes me
wonder if your kernel is really using KMS. When booted, does the framebuffer
display in native resolution ?
I switched back to Xorg from [extra] for stability matters. [testing] being
for ... well, testing.

Re: [arch-general] X dead with intel video - what provides module "fbcon"

[pascal]

Le Thu, 15 Oct 2009 19:46:36 -0500
"David C. Rankin"  a écrit:

> On Thursday 15 October 2009 06:37:43 pm Mikael Eriksson wrote:
> > On Thu, Oct 15, 2009 at 06:30:29PM -0500, David C. Rankin wrote:
> > > Guys,
> > >
> > > After picking around in the logs, one recurring error seems to be:
> > >
> > > FATAL: Module fbcon not found.
> > 
> > This comes from modprobe.
> > 
> > > What provides the "fbcon" module? I presume it some framebuffer connect
> > > module. I have loaded xf86-video-fbdev package, but still no luck.
> > 
> > fbcon is a kernel module, but it should be compiled into the kernel.
> > Do you have the latest kernel26?
> > 
> > > Still stumped with intel :-(
> > 
> 
> Yep
> 
> kernel26-2.6.31.4-1-i686.pkg.tar.gz
> 
> 

this error about fbcon module not found can be ignored, fbcon seems to be
builtin in the kernel and not as a module, hence "module not found". See
http://bbs.archlinux.org/viewtopic.php?id=79362

Re: [arch-general] X fails to start with intel card after latest kernel update

[pascal]

Le Sat, 10 Oct 2009 00:30:53 -0500
"David C. Rankin"  a écrit:

> 
> Here is what is showing up in the errors.log that shows the problem started 
> with the updates on 10/8
> 

Could you post the 60-70 last lines of /var/log/pacman.log ?

Re: [arch-general] X fails to start with intel card after latest kernel update

[pascal]

Le Sat, 17 Oct 2009 09:13:34 -0500
"David C. Rankin"  a écrit:

> 
> Sure, the whole log is here:
> 
> http://www.3111skyline.com/download/Archlinux/bugs/supersff/pacman.log.bz2
> 
> I have put all the files related to the bug in that directory:
> 
> http://www.3111skyline.com/download/Archlinux/bugs/supersff/
> 

The thing is your pacman log stops at 2009.10.09 and there's no information
related to the xorg (and intel drivers) upgrade. It might not be related but
who knows...

Re: [arch-general] Howto create initial xorg.conf for intel 915?

[pascal]

Le Mon, 18 May 2009 05:12:33 -0500,
"David C. Rankin, J.D.,P.E."  a écrit :

> On or about Monday 18 May 2009 at approximately 05:06:28 Jan de Groot 
> composed:
> > On Mon, 2009-05-18 at 04:51 -0500, David C. Rankin, J.D.,P.E. wrote:
> > > Listmates:
> > >
> > > I have been throught
> > > http://wiki.archlinux.org/index.php/Intel_Graphics, and even
> > > added the section on howto calculate your VideoRam value, but I
> > > didn't find anything about generating an initial xorg.conf for
> > > the intel card.
> > >
> > > Currently I have no xorg.conf and things are working, but not as
> > > fast as they could. I would like to configure the card to use UXA
> > > accell, but I need an xorg.conf to tweak. Anybody know a quick
> > > way to create one?
> > >
> > > Thanks.
> >
> > Xorg -configure
> > Then move /root/xorg.conf.new to /etc/X11/xorg.conf and add:
> > Option "AccelMethod" "UXA"
> > To the section of your videocard.
> >
> > No need to set other things like videoram, etc.
> 
> Jan, Leeyee
> 
>   Thank you both. That's just what I needed.
> 
You could also enable kernel modesetting, and it will use UXA
automatically, so no xorg.conf needed.

Re: [arch-general] nouveau and nividia bios extract

[Pascal Piallat]

It's building fine on my computer (x86_64), is your system up-to-date ? Are
you sure you have all dependencies installed?

2014-10-25 21:38 GMT+02:00 pete nikolic :

>
> Hi folks .
>
> One of those i cant sort on my own i am afraid
>
>
> I have downloaded the nouveau-fw package  run makepkg it down loads the
> needed files
> all ok but the fails completely and silently if i try to run the NVIDIA
> package
> with the --extract-only  switch  i get complained at that the package is
> intended
> for the  x86 platform and i am using the x86_64 platform .
>
> According to the package page on the Arch site it should work help
> please
> totally stumped right now .
>
>
>
> Thanks Pete .
>
> --
> Illegitimi non carborundum . ro for the purists out there
> Noli nothis permittere te terere.
>

[arch-general] python 3.5 with or without python 3.7

[Pascal via arch-general]

hello members (and happy new year),
my system is up to date and works with python 3.7.
for a specific need, I want to install python 3.5 but cannot go down
because its installation breaks an dependency: :: installing python
(3.5.2-1) breaks dependency 'python>=3.7' required by libreoffice-still.
what do you think is the easiest way to achieve my goals ?
regards, lacsaP.

Re: [arch-general] python 3.5 with or without python 3.7

[Pascal via arch-general]

my package comes from https://archive.archlinux.org/packages/p/python/ and
it's not an AUR package.
if I understood correctly, I wouldn't have this dependency problem if I
install the AUR python35 package: is that correct?

Le lun. 7 janv. 2019 à 14:38, Eli Schwartz via arch-general <
arch-general@archlinux.org> a écrit :

> On 1/7/19 8:34 AM, Pascal via arch-general wrote:
> > hello members (and happy new year),
> > my system is up to date and works with python 3.7.
> > for a specific need, I want to install python 3.5 but cannot go down
> > because its installation breaks an dependency: :: installing python
> > (3.5.2-1) breaks dependency 'python>=3.7' required by libreoffice-still.
> > what do you think is the easiest way to achieve my goals ?
> > regards, lacsaP.
>
>
> python35 is an AUR package that is *not* the "python" package pinned at
> version 3.5
>
> You are not permitted to change the version of the "python" package, as
> it will break all python-related software in the entire distribution, of
> which there is a tremendous amount. If you do it, you are no longer
> running Arch Linux.
>
> There is absolutely no issue with installing the python35 package next
> to the python package, it will work flawlessly.
>
> :)
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>
>

Re: [arch-general] python 3.5 with or without python 3.7

[Pascal via arch-general]

what would be the command line for pipenv (eg. user wide) ?

Le lun. 7 janv. 2019 à 14:36, Mr.Elendig  a écrit :

> On 07/01/2019 14:34, Pascal via arch-general wrote:
> > hello members (and happy new year),
> > my system is up to date and works with python 3.7.
> > for a specific need, I want to install python 3.5 but cannot go down
> > because its installation breaks an dependency: :: installing python
> > (3.5.2-1) breaks dependency 'python>=3.7' required by libreoffice-still.
> > what do you think is the easiest way to achieve my goals ?
> > regards, lacsaP.
> Install python35 from aur if you need it system wide or use pyenv if not.
>

Re: [arch-general] python 3.5 with or without python 3.7

[Pascal via arch-general]

thanks
ok, this is the last top post ;-)

Le lun. 7 janv. 2019 à 14:55, Mr.Elendig  a écrit :

> On 07/01/2019 14:52, Pascal via arch-general wrote:
> > what would be the command line for pipenv (eg. user wide) ?
> >
> > Le lun. 7 janv. 2019 à 14:36, Mr.Elendig  a
> écrit :
> >
> >> On 07/01/2019 14:34, Pascal via arch-general wrote:
> >>> hello members (and happy new year),
> >>> my system is up to date and works with python 3.7.
> >>> for a specific need, I want to install python 3.5 but cannot go down
> >>> because its installation breaks an dependency: :: installing python
> >>> (3.5.2-1) breaks dependency 'python>=3.7' required by
> libreoffice-still.
> >>> what do you think is the easiest way to achieve my goals ?
> >>> regards, lacsaP.
> >> Install python35 from aur if you need it system wide or use pyenv if
> not.
> >>
>
> Pyenv[1] not pipenv.
>
> And please don't top post :=)
>
> [1]https://github.com/pyenv/pyenv
>

Re: [arch-general] python 3.5 with or without python 3.7

[Pascal via arch-general]

pyenv <https://github.com/pyenv/pyenv> did the job perfectly !
thank you for this tip :-)
regards, lacsaP.

Le lun. 7 janv. 2019 à 14:59, Pascal  a écrit :

> thanks
> ok, this is the last top post ;-)
>
> Le lun. 7 janv. 2019 à 14:55, Mr.Elendig  a
> écrit :
>
>> On 07/01/2019 14:52, Pascal via arch-general wrote:
>> > what would be the command line for pipenv (eg. user wide) ?
>> >
>> > Le lun. 7 janv. 2019 à 14:36, Mr.Elendig  a
>> écrit :
>> >
>> >> On 07/01/2019 14:34, Pascal via arch-general wrote:
>> >>> hello members (and happy new year),
>> >>> my system is up to date and works with python 3.7.
>> >>> for a specific need, I want to install python 3.5 but cannot go down
>> >>> because its installation breaks an dependency: :: installing python
>> >>> (3.5.2-1) breaks dependency 'python>=3.7' required by
>> libreoffice-still.
>> >>> what do you think is the easiest way to achieve my goals ?
>> >>> regards, lacsaP.
>> >> Install python35 from aur if you need it system wide or use pyenv if
>> not.
>> >>
>>
>> Pyenv[1] not pipenv.
>>
>> And please don't top post :=)
>>
>> [1]https://github.com/pyenv/pyenv
>>
>

[arch-general] kernel compilation

[Pascal via arch-general]

hello members,

I'm not used to compiling and therefore even less to compiling the
kernel

I followed the instructions given by this page
.

after compilation, if I modify/patch file src/linux-4.19/block/blk-core.c,
do I have to replace the kernel ? the kernel and all its modules ? or just
the module concerned by the change (if it concerns a module) ?

regards, lacsaP.

[arch-general] adb backup broken named pipe

[Pascal via arch-general]

hello,

I'm looking for a solution for the problem below : all leads are welcome !

the adb tool is able to make a backup of a smartphone in a file:
adb backup -all -f mybackup.ab

however, the file mybackup.ab has a particular format that prevents it from
being used "simply".
to convert it into a tgz archive, it is possible to do this:
( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00\x00"; tail -c +25
mybackup.ab ) > mybackup.tgz

but in this case, I can easily end up with two files of 16Gb or more...
to avoid this volume problem, I tried to do this:
mkfifo backup.fifo
adb backup -all -f backup.fifo &
( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00" ; tail -c +25
backup.fifo) > mybackup.tgz

but adb systematically breaks my named pipe and my code doesn't work as
expected.
how to prevent adb from breaking the named pipe ?
I'm considering using fuse but there may be a simpler way...

regards, lacsaP.

Re: [arch-general] adb backup broken named pipe

[Pascal via arch-general]

when I looked a little closer at what adb backup was doing, I realized that
it was communicating with an adb server running in parallel and, by
mimicking the conversation with python, I managed to get what I wanted.
*(note that a small error was present in the question : the string to use
with printf is "\x1f\x8b\x08\x00\x00\x00\x00\x00").*

I still have a slight problem because the tar command ends with an error :
*(the same error is also present with adb, printf and tail).*

$ adb devices
List of devices attached
CB5A2B0M9Rdevice
$ python3 adbackup.py > /tmp/mybackup.tgz
$ tar tvzf /tmp/mybackup.tgz
... all my files are here :-)
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now

adbackup.py :

#!/usr/bin/python3

# strace adb backup -all -f /tmp/backup.ab
#...
#unlink("/tmp/backup.ab")= 0
#creat("/tmp/backup.ab", 0640)   = 3
#...
#socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
#bind(4, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
#connect(4, {sa_family=AF_INET, sin_port=htons(5037),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
#setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
#write(4, "0012host:transport-any", 22)  = 22
#read(4, "OKAY", 4)  = 4
#write(4, "000ebackup: '-all'", 18)  = 18
#read(4, "OKAY", 4)  = 4
#fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
#write(1, "Now unlock your device and confi"..., 59) = 59
#read(4, "ANDROID BACKUP\n4\n1\nnone\n", 32768) = 24
#write(3, "ANDROID BACKUP\n4\n1\nnone\n", 24) = 24
#read(4, "x\332", 32768) = 2
#write(3, "x\332", 2)= 2
#read(4, "\344VY\256\35E\f}\337o\25\254
\361\\U\253A\256\301(\37$Q\22\366\317\251\233\274(\240"..., 32768) = 967

import socket, sys
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("localhost", 5037))
s.sendall(b"0012host:transport-any")
data = s.recv(4)# b"OKAY"
s.sendall(b"000ebackup: '-all'")
data = s.recv(4)# b"OKAY"
data = s.recv(32768)# b"ANDROID BACKUP\n4\n1\nnone\n"
sys.stdout.buffer.write(b"\x1f\x8b\x08\x00\x00\x00\x00\x00")
data = s.recv(32768)
while data:
sys.stdout.buffer.write(data)
data = s.recv(32768)

regards, lacsaP.

Le jeu. 16 mai 2019 à 10:57, Pascal  a écrit :

> hello,
>
> I'm looking for a solution for the problem below : all leads are welcome !
>
> the adb tool is able to make a backup of a smartphone in a file:
> adb backup -all -f mybackup.ab
>
> however, the file mybackup.ab has a particular format that prevents it
> from being used "simply".
> to convert it into a tgz archive, it is possible to do this:
> ( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00\x00"; tail -c +25
> mybackup.ab ) > mybackup.tgz
>
> but in this case, I can easily end up with two files of 16Gb or more...
> to avoid this volume problem, I tried to do this:
> mkfifo backup.fifo
> adb backup -all -f backup.fifo &
> ( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00" ; tail -c +25
> backup.fifo) > mybackup.tgz
>
> but adb systematically breaks my named pipe and my code doesn't work as
> expected.
> how to prevent adb from breaking the named pipe ?
> I'm considering using fuse but there may be a simpler way...
>
> regards, lacsaP.
>

Re: [arch-general] adb backup broken named pipe

[Pascal via arch-general]

does anyone have any idea what should be added/removed at the end of the
data to properly complete the tgz archive ?

regards, lacsaP.

Le jeu. 16 mai 2019 à 16:00, Pascal  a écrit :

> when I looked a little closer at what adb backup was doing, I realized
> that it was communicating with an adb server running in parallel and, by
> mimicking the conversation with python, I managed to get what I wanted.
> *(note that a small error was present in the question : the string to use
> with printf is "\x1f\x8b\x08\x00\x00\x00\x00\x00").*
>
> I still have a slight problem because the tar command ends with an error :
> *(the same error is also present with adb, printf and tail).*
>
> $ adb devices
> List of devices attached
> CB5A2B0M9Rdevice
> $ python3 adbackup.py > /tmp/mybackup.tgz
> $ tar tvzf /tmp/mybackup.tgz
> ... all my files are here :-)
> gzip: stdin: unexpected end of file
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
>
> adbackup.py :
>
> #!/usr/bin/python3
>
> # strace adb backup -all -f /tmp/backup.ab
> #...
> #unlink("/tmp/backup.ab")= 0
> #creat("/tmp/backup.ab", 0640)   = 3
> #...
> #socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
> #bind(4, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> #connect(4, {sa_family=AF_INET, sin_port=htons(5037),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> #setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> #write(4, "0012host:transport-any", 22)  = 22
> #read(4, "OKAY", 4)  = 4
> #write(4, "000ebackup: '-all'", 18)  = 18
> #read(4, "OKAY", 4)  = 4
> #fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
> #write(1, "Now unlock your device and confi"..., 59) = 59
> #read(4, "ANDROID BACKUP\n4\n1\nnone\n", 32768) = 24
> #write(3, "ANDROID BACKUP\n4\n1\nnone\n", 24) = 24
> #read(4, "x\332", 32768) = 2
> #write(3, "x\332", 2)= 2
> #read(4, "\344VY\256\35E\f}\337o\25\254
> \361\\U\253A\256\301(\37$Q\22\366\317\251\233\274(\240"..., 32768) = 967
>
> import socket, sys
> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> s.connect(("localhost", 5037))
> s.sendall(b"0012host:transport-any")
> data = s.recv(4)# b"OKAY"
> s.sendall(b"000ebackup: '-all'")
> data = s.recv(4)# b"OKAY"
> data = s.recv(32768)# b"ANDROID BACKUP\n4\n1\nnone\n"
> sys.stdout.buffer.write(b"\x1f\x8b\x08\x00\x00\x00\x00\x00")
> data = s.recv(32768)
> while data:
> sys.stdout.buffer.write(data)
> data = s.recv(32768)
>
> regards, lacsaP.
>
> Le jeu. 16 mai 2019 à 10:57, Pascal  a écrit :
>
>> hello,
>>
>> I'm looking for a solution for the problem below : all leads are welcome !
>>
>> the adb tool is able to make a backup of a smartphone in a file:
>> adb backup -all -f mybackup.ab
>>
>> however, the file mybackup.ab has a particular format that prevents it
>> from being used "simply".
>> to convert it into a tgz archive, it is possible to do this:
>> ( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00\x00"; tail -c +25
>> mybackup.ab ) > mybackup.tgz
>>
>> but in this case, I can easily end up with two files of 16Gb or more...
>> to avoid this volume problem, I tried to do this:
>> mkfifo backup.fifo
>> adb backup -all -f backup.fifo &
>> ( printf "\x1f\x8b\x08\x08\x00\x00\x00\x00\x00\x00" ; tail -c +25
>> backup.fifo) > mybackup.tgz
>>
>> but adb systematically breaks my named pipe and my code doesn't work as
>> expected.
>> how to prevent adb from breaking the named pipe ?
>> I'm considering using fuse but there may be a simpler way...
>>
>> regards, lacsaP.
>>
>

Re: [arch-general] adb backup broken named pipe

[Pascal via arch-general]

*(sorry, bad Ctrl-C Ctrl-V)*
yes, but I have two constraints, the second being directly related to the
first : limited storage space and access to data backed up through
archivemount that does not support the android backup format.

Le ven. 17 mai 2019 à 11:49, Pascal  a écrit :

> Indeed, but it has to face two constraints, the second being directly
> related to the first : limited storage space and access to the data backed
> up through archivemount which does not support the android backup format.
>
> Le ven. 17 mai 2019 à 10:32, Ralph Corderoy  a
> écrit :
>
>> Hi Pascal,
>>
>> > I still have a slight problem because the tar command ends with an
>> error :
>> > *(the same error is also present with adb, printf and tail).*
>> ..
>> > $ python3 adbackup.py > /tmp/mybackup.tgz
>> > $ tar tvzf /tmp/mybackup.tgz
>> > ... all my files are here :-)
>> > gzip: stdin: unexpected end of file
>> > tar: Child returned status 1
>> > tar: Error is not recoverable: exiting now
>>
>> Why not keep the non-tar file long term and convert it to gzip'd tar
>> format when required.  That way you'll be able to improve your
>> conversion over time, and not break if adb changes its format.  That
>> breakage could go unnoticed until it's too late to re-backup the data.
>>
>> (printf ... && cat foo.ab) | tar ...
>>
>> --
>> Cheers, Ralph.
>>
>

Re: [arch-general] adb backup broken named pipe

[Pascal via arch-general]

Indeed, but it has to face two constraints, the second being directly
related to the first : limited storage space and access to the data backed
up through archivemount which does not support the android backup format.

Le ven. 17 mai 2019 à 10:32, Ralph Corderoy  a
écrit :

> Hi Pascal,
>
> > I still have a slight problem because the tar command ends with an error
> :
> > *(the same error is also present with adb, printf and tail).*
> ..
> > $ python3 adbackup.py > /tmp/mybackup.tgz
> > $ tar tvzf /tmp/mybackup.tgz
> > ... all my files are here :-)
> > gzip: stdin: unexpected end of file
> > tar: Child returned status 1
> > tar: Error is not recoverable: exiting now
>
> Why not keep the non-tar file long term and convert it to gzip'd tar
> format when required.  That way you'll be able to improve your
> conversion over time, and not break if adb changes its format.  That
> breakage could go unnoticed until it's too late to re-backup the data.
>
> (printf ... && cat foo.ab) | tar ...
>
> --
> Cheers, Ralph.
>

[arch-general] journalctl

[Pascal via arch-general]

hello,
when I use journalctl to track system events, I introduce line breaks for
better readability.
like multitail, I would like to introduce more verbose line breaks...
I wrote these few lines but it doesn't work as expected :

exec 6<&0
exec 0< <( while :; do read -sn1 k; echo $'\n'"# $( date +%H:%M:%S )
---"$'\n'; done )
journalctl -f
exec 0<&6 6<&-

the second instruction "exec 0< <( while..." played alone works perfectly
in my terminal, but not as a redirection for journalctl.
any leads ?
regards, lacsaP.

[arch-general] broken pipe

[Pascal via arch-general]

hello,

to avoid having to read twice the entire large file, I use the tee tool in
this way to calculate two checksums "simultaneously" :

file_info(){
echo -n ${1:=/dev/stdin}$'\t'
(
tee < "${1}" \
>( md5sum >&3 ) \
>( sha1sum >&3 ) \
>/dev/null
) 3>&1 |
tr '\n' '\t'
echo
}

it works perfectly because both tools used, md5sum and sha1sum, consume all
the data.

on the other hand, the function returns wrong fingerprints if I insert a
tool like file :

file_info(){
echo -n ${1:=/dev/stdin}$'\t'
(
tee < "${1}" \
>( file --mime-type -b -e compress -e tar -e elf - >&3 ) \
>( md5sum >&3 ) \
>( sha1sum >&3 ) \
>/dev/null
) 3>&1 |
tr '\n' '\t'
echo
}

it no longer works because the data flow is quickly interrupted by tee
which does not consume all the data.

do you know a way to get the file type in parallel with the fingerprint ?

getting its type is just an example : the idea is to open the file only
once...

regards, lacsaP.

Re: [arch-general] broken pipe

[Pascal via arch-general]

that's awesome, it works !
it was so simple with cat taking over and consuming the data until the end !
(I added a redirect to /dev/null to cat)
big thank you.

Le mer. 18 déc. 2019 à 16:19, mar77i via arch-general <
arch-general@archlinux.org> a écrit :

> ‐‐‐ Original Message ‐‐‐
> On Wednesday, December 18, 2019 3:20 PM, Pascal via arch-general <
> arch-general@archlinux.org> wrote:
>
> > hello,
> >
> > it works perfectly because both tools used, md5sum and sha1sum, consume
> all
> > the data.
> >
> > on the other hand, the function returns wrong fingerprints if I insert a
> > tool like file :
>
>
> ...just do >(file --mime-type -b -e compress -e tar -e elf - >&3; cat) ?
>
>
> Sent with ProtonMail Secure Email.
>

Re: [arch-general] broken pipe

[Pascal via arch-general]

it depends a little bit on the context in which the function will be played
:
- with an SSD disk, the playback of a large file is very fast,
- with a lot of available memory, the file is cached at its first reading
and subsequent readings are almost instantaneous.
if these two conditions are met, indeed, I am not sure that the function
brings a real benefit.
otherwise, there is a real interest in using the function.

the tests below were performed on a large file placed on a USB 3.0 key.

ll -hgG elementaryos-5.1-stable.20191202.iso
-rw-r--r-- 1 1.4G Dec 17 14:22 elementaryos-5.1-stable.20191202.iso

here the large file is kept in cache :

pv elementaryos-5.1-stable.20191202.iso > /dev/null
1.37GiB 0:00:35 [39.4MiB/s] [>] 100%
pv elementaryos-5.1-stable.20191202.iso > /dev/null
1.37GiB 0:00:00 [4.51GiB/s] [>] 100%

time ( file --mime-type -b -e compress -e tar -e elf
elementaryos-5.1-stable.20191202.iso; md5sum
elementaryos-5.1-stable.20191202.iso; sha1sum
elementaryos-5.1-stable.20191202.iso )
application/octet-stream
d1addd17377aa73700680ff937d7a0f4  elementaryos-5.1-stable.20191202.iso
cbe37d55c44db5bb0ab0ae6f5bf0eb96209bb16f
 elementaryos-5.1-stable.20191202.iso
real 0m4.680s
user 0m4.298s
sys 0m0.318s

file_info(){ echo -n ${1:=/dev/stdin}$'\t'; ( tee < "${1}" >( file
--mime-type -b -e compress -e tar -e elf - >&3; cat >/dev/null ) >( md5sum
>&3 ) >( sha1sum >&3 ) >/dev/null; ) 3>&1 | tr '\n' '\t'; echo; }

time ( file_info elementaryos-5.1-stable.20191202.iso )
elementaryos-5.1-stable.20191202.iso application/octet-stream
cbe37d55c44db5bb0ab0ae6f5bf0eb96209bb16f  -
d1addd17377aa73700680ff937d7a0f4  -
real 0m3.435s
user 0m0.113s
sys 0m1.176s

now the cache is cleared between each access (eg. limited available memory)
:

function flush { sync && sysctl -q vm.drop_caches=3; }

flush; pv elementaryos-5.1-stable.20191202.iso > /dev/null
1.37GiB 0:00:35 [39.4MiB/s] [>] 100%
flush; pv elementaryos-5.1-stable.20191202.iso > /dev/null
1.37GiB 0:00:35 [39.4MiB/s] [>] 100%

flush; time ( file --mime-type -b -e compress -e tar -e elf
elementaryos-5.1-stable.20191202.iso; flush; md5sum
elementaryos-5.1-stable.20191202.iso; flush; sha1sum
elementaryos-5.1-stable.20191202.iso )
application/octet-stream
d1addd17377aa73700680ff937d7a0f4  elementaryos-5.1-stable.20191202.iso
cbe37d55c44db5bb0ab0ae6f5bf0eb96209bb16f
 elementaryos-5.1-stable.20191202.iso

real 1m11.054s
user 0m8.092s
sys 0m1.441s

flush; time ( file_info elementaryos-5.1-stable.20191202.iso )
elementaryos-5.1-stable.20191202.iso application/octet-stream
cbe37d55c44db5bb0ab0ae6f5bf0eb96209bb16f  -
d1addd17377aa73700680ff937d7a0f4  -

real 0m35.217s
user 0m0.316s
sys 0m2.146s

Le mer. 18 déc. 2019 à 16:42, Andy Pieters 
a écrit :

> On Wed, 18 Dec 2019 at 15:32, Pascal via arch-general
>  wrote:
> >
> > that's awesome, it works !
> > it was so simple with cat taking over and consuming the data until the
> end !
> > (I added a redirect to /dev/null to cat)
> > big thank you.
>
> I'm interested in the amount of effort you put into this. Isn't the
> overhead of the pipes etc going to negate any memory/speed
> improvements you may get from only opening the file once or is there
> another consideration at play here?
>

Re: [arch-general] broken pipe

[Pascal via arch-general]

hi Ralph,

thank you for that clarification.
the function works a little faster with them.

file_info(){ echo -n ${1:=/dev/stdin}$'\t'; ( tee < "${1}" >( file
--mime-type -b -e compress -e tar -e elf - >&3; cat >/dev/null ) >( md5sum
>&3 ) >( sha1sum >&3 ) >/dev/null; ) 3>&1 | tr '\n' '\t'; echo; }

pv big.tar > /dev/null
1,71GiO 0:00:00 [5,32GiB/s]
[==>]
100%

time ( for i in $( seq 24 ); do file_info big.tar ; done )
big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
-6989542fabd98b04086524d1106b7907  -
...
big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
-6989542fabd98b04086524d1106b7907  -

real3m2,712s
user0m14,988s
sys1m13,303s

file_info(){ echo -n ${1:=/dev/stdin}$'\t'; ( trap "" pipe; tee < "${1}" >(
md5sum >&3 ) >( sha1sum >&3 ) | file --mime-type -b -e compress -e tar -e
elf - ) 3>&1 | tr '\n' '\t'; echo; }

pv big.tar > /dev/null
1,71GiO 0:00:00 [5,37GiB/s]
[==>]
100%

time ( for i in $( seq 24 ); do file_info big.tar ; done )
big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
-6989542fabd98b04086524d1106b7907  -
...
big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
-6989542fabd98b04086524d1106b7907  -

real2m36,013s
user0m9,349s
sys0m50,257s

Le jeu. 19 déc. 2019 à 11:59, Ralph Corderoy  a
écrit :

> Hi Pascal,
>
> > file_info(){
> > echo -n ${1:=/dev/stdin}$'\t'
> > (
> > tee < "${1}" \
> > >( file --mime-type -b -e compress -e tar -e elf - >&3 ) \
> > >( md5sum >&3 ) \
> > >( sha1sum >&3 ) \
> > >/dev/null
> > ) 3>&1 |
> > tr '\n' '\t'
> > echo
> > }
> >
> > it no longer works because the data flow is quickly interrupted by tee
> > which does not consume all the data.
>
> You're missing the reason why.  tee(1) receives a SIGPIPE because it
> writes to a pipe that's closed.  Adding a cat(1) is a waste of CPU, as
> is discarding tee's stdout instead of using it for one of the workers.
>
> Examine these differences.
>
> $ seq 31415 | wc
>   31415   31415  177384
> $ seq 31415 | tee >(sed q) >(wc) > >(tr -d 42 | wc); sleep 1
> 1
>   14139   14109   62130
>   12773   12774   65536
> $ seq 31415 | (trap '' pipe; tee >(sed q) >(wc) > >(tr -d 42 | wc));
> sleep 1
> 1
>   31415   31369  142504
>   31415   31415  177384
> $
>
> Note the output of the commands can be in any order, and intermingle if
> they're long enough.
>
> tee(1) has -p and --output-error but they're not as specific as stating
> SIGPIPE is expected for just one worker.
>
> --
> Cheers, Ralph.
>

Re: [arch-general] broken pipe

[Pascal via arch-general]

hi,
https://github.com/patatetom/hashs
and merry Christmas.

Le jeu. 19 déc. 2019 à 23:16, Pascal  a écrit :

> hi Ralph,
>
> thank you for that clarification.
> the function works a little faster with them.
>
> file_info(){ echo -n ${1:=/dev/stdin}$'\t'; ( tee < "${1}" >( file
> --mime-type -b -e compress -e tar -e elf - >&3; cat >/dev/null ) >( md5sum
> >&3 ) >( sha1sum >&3 ) >/dev/null; ) 3>&1 | tr '\n' '\t'; echo; }
>
> pv big.tar > /dev/null
> 1,71GiO 0:00:00 [5,32GiB/s]
> [==>]
> 100%
>
> time ( for i in $( seq 24 ); do file_info big.tar ; done )
> big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
> -6989542fabd98b04086524d1106b7907  -
> ...
> big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
> -6989542fabd98b04086524d1106b7907  -
>
> real3m2,712s
> user0m14,988s
> sys1m13,303s
>
> file_info(){ echo -n ${1:=/dev/stdin}$'\t'; ( trap "" pipe; tee < "${1}"
> >( md5sum >&3 ) >( sha1sum >&3 ) | file --mime-type -b -e compress -e tar
> -e elf - ) 3>&1 | tr '\n' '\t'; echo; }
>
> pv big.tar > /dev/null
> 1,71GiO 0:00:00 [5,37GiB/s]
> [==>]
> 100%
>
> time ( for i in $( seq 24 ); do file_info big.tar ; done )
> big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
> -6989542fabd98b04086524d1106b7907  -
> ...
> big.tarapplication/x-gtar53f0d0240e5ddc94266087ec96ebb802236fa0bc
> -6989542fabd98b04086524d1106b7907  -
>
> real2m36,013s
> user0m9,349s
> sys0m50,257s
>
> Le jeu. 19 déc. 2019 à 11:59, Ralph Corderoy  a
> écrit :
>
>> Hi Pascal,
>>
>> > file_info(){
>> > echo -n ${1:=/dev/stdin}$'\t'
>> > (
>> > tee < "${1}" \
>> > >( file --mime-type -b -e compress -e tar -e elf - >&3 ) \
>> > >( md5sum >&3 ) \
>> > >( sha1sum >&3 ) \
>> > >/dev/null
>> > ) 3>&1 |
>> > tr '\n' '\t'
>> > echo
>> > }
>> >
>> > it no longer works because the data flow is quickly interrupted by tee
>> > which does not consume all the data.
>>
>> You're missing the reason why.  tee(1) receives a SIGPIPE because it
>> writes to a pipe that's closed.  Adding a cat(1) is a waste of CPU, as
>> is discarding tee's stdout instead of using it for one of the workers.
>>
>> Examine these differences.
>>
>> $ seq 31415 | wc
>>   31415   31415  177384
>> $ seq 31415 | tee >(sed q) >(wc) > >(tr -d 42 | wc); sleep 1
>> 1
>>   14139   14109   62130
>>   12773   12774   65536
>> $ seq 31415 | (trap '' pipe; tee >(sed q) >(wc) > >(tr -d 42 | wc));
>> sleep 1
>> 1
>>   31415   31369  142504
>>   31415   31415  177384
>> $
>>
>> Note the output of the commands can be in any order, and intermingle if
>> they're long enough.
>>
>> tee(1) has -p and --output-error but they're not as specific as stating
>> SIGPIPE is expected for just one worker.
>>
>> --
>> Cheers, Ralph.
>>
>

[arch-general] kernel full compilation ?

[Pascal via arch-general]

hello,

I need to introduce a small modification in linux-5.4.23/block/blk-core.o :
do I need to recompile completely (~4 hours) or is there a way to shorten
the compilation time ?

I followed Kernel/Arch_Build_System
.

regards, lacsaP.

Re: [arch-general] kernel full compilation ?

[Pascal via arch-general]

no, it's not a bug.

it's necessary to recompile completely even if the kernel I'm using is the
same as the one I want to apply a small modification on ?

Le mar. 3 mars 2020 à 14:00, Giancarlo Razzolini 
a écrit :

> Em março 3, 2020 9:54 Pascal via arch-general escreveu:
> > hello,
> >
> > I need to introduce a small modification in
> linux-5.4.23/block/blk-core.o :
> > do I need to recompile completely (~4 hours) or is there a way to shorten
> > the compilation time ?
> >
> > I followed Kernel/Arch_Build_System
> > <https://wiki.archlinux.org/index.php/Kernel/Arch_Build_System>.
> >
> > regards, lacsaP.
> >
>
> If this is a bug, you might want to ask the linux-lts maintainer to
> include a
> patch for this. But, regardless of that, you'll have to compile it, yes.
>
> Regards,
> Giancarlo Razzolini

Re: [arch-general] kernel full compilation ?

[Pascal via arch-general]

thank you for these details.

regards, lacsaP.

Le mar. 3 mars 2020 à 14:10, José Luis via arch-general <
arch-general@archlinux.org> a écrit :

> Check ccache, it may help with recompile time after the first compilation
> is done.
>

Re: [arch-general] kernel full compilation ?

[Pascal via arch-general]

yes, I've just recompiled and this second time was much faster !

to be more precise, here is the very small modification made to the file
mentioned above :

--- src/linux-5.4.23/block/blk-core.c 2020-02-28 17:22:29.0 +0100
+++ /tmp/blk-core.c 2020-03-03 14:25:56.049803851 +0100
@@ -799,7 +799,7 @@
  "to read-only block-device %s (partno %d)\n",
  bio_devname(bio, b), part->partno);
  /* Older lvm-tools actually trigger this */
- return false;
+ return true;
  }

  return false;

Le mar. 3 mars 2020 à 14:19, Caleb Maclennan  a écrit :

> On Tue, Mar 3, 2020 at 4:06 PM Pascal via arch-general <
> arch-general@archlinux.org> wrote:
>
>> it's necessary to recompile completely even if the kernel I'm using is the
>> same as the one I want to apply a small modification on ?
>>
>
> Yes.
>
> The only small consolation is that once you compile it once and have a
> source tree that has been fully built on your system, further small changes
> and re-compiles will go much faster because it will figure out _some_ of
> the things it doesn't need to do again. I the case of the kernel, it still
> won't be fast.
>
> Caleb
>

Re: [arch-general] kernel full compilation ?

[Pascal via arch-general]

this is not a patch :-)
this is only for testing (https://github.com/msuhanov/Linux-write-blocker)

Pascal

Le mar. 3 mars 2020 à 17:36, Filipe Laíns via arch-general <
arch-general@archlinux.org> a écrit :

> On Tue, 2020-03-03 at 14:29 +0100, Pascal via arch-general wrote:
> > yes, I've just recompiled and this second time was much faster !
> >
> > to be more precise, here is the very small modification made to the
> > file
> > mentioned above :
> >
> > --- src/linux-5.4.23/block/blk-core.c 2020-02-28 17:22:29.0
> > +0100
> > +++ /tmp/blk-core.c 2020-03-03 14:25:56.049803851 +0100
> > @@ -799,7 +799,7 @@
> >   "to read-only block-device %s (partno %d)\n",
> >   bio_devname(bio, b), part->partno);
> >   /* Older lvm-tools actually trigger this */
> > - return false;
> > + return true;
> >   }
>
> This seems very wrong. Has this patch been upstreamed?
>
> Filipe Laíns
>

Re: [arch-general] kernel full compilation ?

[Pascal via arch-general]

moreover, this seems to only concern the modules, i.e. the parts external
parts of the kernel, which is not the case with blk-core.c...

Le mar. 3 mars 2020 à 23:56, Filipe Laíns via arch-general <
arch-general@archlinux.org> a écrit :

> On Tue, 2020-03-03 at 16:50 +0200, Alexander Kapshuk via arch-general
> wrote:
> > You could just do:
> > make M=block ;to rebuild the part of the kernel modified
> > make ;to rebuild all other object files affected and to relink the
> kernel image
> >
> > from the root of your kernel source tree, followed by:
> > make modules_install
> > make install
> > etc
> >
> > See http://files.kroah.com/lkn/lkn_pdf/ch04.pdf, Building Only a
> > Portion of the Kernel.
>
> Please don't. This is completely unsupported.
>
> Filipe Laíns
>

Re: [arch-general] Multi-threaded mkinitpcio

[Pascal via arch-general]

hi,

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf
: it will considerably reduce the compression time.

grep COMP /etc/mkinitcpio.conf
# COMPRESSION
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
COMPRESSION="lz4"
# COMPRESSION_OPTIONS
#COMPRESSION_OPTIONS=()

see here

for quick  benchmarks...

regards, lacsaP.

Le ven. 3 avr. 2020 à 08:08, Ralf Mardorf via arch-general <
arch-general@archlinux.org> a écrit :

> On Fri, 3 Apr 2020 04:36:37 +0200, mpan wrote:
> >Half of the time mkinitcpio was waiting for disk I/O.
>
> Even while it's unlikely that only mkinitcpio suffers from a damaged
> HDD and even while smartctl not necessarily does show issues of a
> already damaged aged HDD, I would run smartctl and take a look, if it
> shows something fishy.
>

Re: [arch-general] Multi-threaded mkinitpcio

[Pascal via arch-general]

I don't quite understand where the reproducibility is broken ?

Amin Vakil says that rebuilding his initrd (when updating kernel and/or
modules) takes a lot of time and the final compression phase can be reduced
by switching to lz4 or lzop. when you go from xz (which may be his case) to
lzop, the difference is remarkable.

Le ven. 3 avr. 2020 à 14:47, Giancarlo Razzolini 
a écrit :

> Em abril 3, 2020 3:17 Pascal via arch-general escreveu:
> > hi,
> >
> > change the COMPRESSION variable to lz4 ou lzop in your
> /etc/mkinitcpio.conf
> > : it will considerably reduce the compression time.
> >
>
> And break reproducibility. Also, I wouldn't say considerably. Might be
> faster,
> but not leaps and bounds faster.
>
> Regards,
> Giancarlo Razzolini
>

Re: [arch-general] Multi-threaded mkinitpcio

[Pascal via arch-general]

thank you for these details.

regard, lacsaP.

Le lun. 6 avr. 2020 à 05:39, Giancarlo Razzolini via arch-general <
arch-general@archlinux.org> a écrit :

> Em abril 4, 2020 12:13 Jelle van der Waa escreveu:
> >
> > multi-threaded compression does not create a predictable reproducible
> > archive (for xz/zstd).
> >
>
> Zstd is multi-thread safe, as far as I know, xz is not. But the kernel does
> not support zstd.
>
> >
> > Sure, has nothing to do with reproducibility however.
> >
>
> It has, because lzop is the only algorithm that produces unreproducible
> builds
> due to them adding their own timestamp, which there's no flag to remove.
> Of course
> lzop will be faster than xz, but mkinitcpio's default is gz, which should
> be comparable,
> at least in speed, with lzop.
>
> Regards,
> Giancarlo Razzolini

[arch-general] /dev/stdin /dev/stdout /dev/stderr in initrd/initramfs

[Pascal via arch-general]

hi list members,

I don't have /dev/std* (eg. links to /proc/self/fd/{0,1,2}) that were
present until a short time ago.

is there any change on this side ? udev ? is it necessary to incorporate a
particular kernel module in initrd/initramfs to find them again ?

regards, lacsaP.