subject:"glibc"


On 2/27/24 16:08, debian-u...@howorth.org.uk wrote:

Gremlin  wrote:


The provider is raspberry foundation and Raspian has been
dis-continued.


There is such a thing as the Raspberry Pi Foundation but they are an
educational charity. Pis are supplied by Raspberry Pi Ltd. Raspbian has
NOT been discontinued, it has simply been renamed Raspberry Pi OS. I
don't know who releases it, though it is released from teh Ltd company
website rather than the Foundation. Perhaps somebody else knows more
detail.




Nope that is just wrong.


https://www.raspbian.org/


Welcome to Raspbian

Raspbian is a free operating system based on Debian optimized for the 
Raspberry Pi hardware. An operating system is the set of basic programs 
and utilities that make your Raspberry Pi run. However, Raspbian 
provides more than a pure OS: it comes with over 35,000 packages, 
pre-compiled software bundled in a nice format for easy installation on 
your Raspberry Pi.


The initial build of over 35,000 Raspbian packages, optimized for best 
performance on the Raspberry Pi, was completed in June of 2012. However, 
Raspbian is still under active development with an emphasis on improving 
the stability and performance of as many Debian packages as possible.


Note: Raspbian is not affiliated with the Raspberry Pi Foundation. 
Raspbian was created by a small, dedicated team of developers that are 
fans of the Raspberry Pi hardware, the educational goals of the 
Raspberry Pi Foundation and, of course, the Debian Project.



Why are you trying to tell someone that has used raspberry pi since the 
original pi came out things that are just not true.


I also build custom OS for the raspberry pi platform and I am well 
versed with them. I have approx a dozen of them from rpi to rpi 5


I have used them for servers on the network including the original pi.

Yes I am aware of theis in the foundation page:

Your Raspberry Pi needs an operating system to work. This is it. 
Raspberry Pi OS (previously called Raspbian) is our official supported 
operating system.


The new OS called Raspberry Pi OS is a new animal.  The foundation used 
raspian and the the Raspberry Pi OS is the foundations, developed by the 
foundation.


--
Hindi madali ang maging ako

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread debian-user

Gremlin  wrote:

> The provider is raspberry foundation and Raspian has been
> dis-continued.

There is such a thing as the Raspberry Pi Foundation but they are an
educational charity. Pis are supplied by Raspberry Pi Ltd. Raspbian has
NOT been discontinued, it has simply been renamed Raspberry Pi OS. I
don't know who releases it, though it is released from teh Ltd company
website rather than the Foundation. Perhaps somebody else knows more
detail.

Re: How to upgrade the GLIBCXX and GLIBC to the specific version


On 2/27/24 10:08, Jeffrey Walton wrote:



Unable to Process Request
We couldn't access the content delivery.

This content has been deleted, doesn't exist, or can't be previewed.

Gonna be hard to do that


OP might then take a look at editing the elf file directly. `objdump
--remove-section .symver blueriver_bitmap_streamer` should do the
trick.


Why?


The OP wants to run his software.

Surely you have a better question than "Why," but I don't know what it is.

Jeff




Nope it is exactly WHY?

Why not install the latest OS for raspberry pi and you won't have an 
issue.  Get it?


--
Hindi madali ang maging ako

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Jeffrey Walton

On Tue, Feb 27, 2024 at 9:28 AM Gremlin  wrote:
>
> On 2/27/24 09:23, Jeffrey Walton wrote:
> > On Tue, Feb 27, 2024 at 8:34 AM Gremlin  
> > wrote:
> >> [...]
> >>> Another option is to rebuild blueriver_bitmap_streamer. Before the
> >>> build, rip out that useless symbol versioning. All that symbol
> >>> versioning does is to cause a DoS and frustrate users.
> >>>
> >>> You can find the ASM directives to rip out the versioning by grepping
> >>> for '.symver'. It will be in an ASM block.
> >>
> >> https://info.semtech.com/blueriver-av-manager
> >>
> >> The source:
> >>
> >> https://semtech.my.salesforce.com/sfc/p/#E000JelG/a/RQ01m7Hx/ptDTNUqlZvD_8F_SbhjtoHaX9jOZ_fKxuauW0cZp5ag?utm_referrer=https%3A%2F%2Finfo.semtech.com%2F
> >>
> >> Unable to Process Request
> >> We couldn't access the content delivery.
> >>
> >> This content has been deleted, doesn't exist, or can't be previewed.
> >>
> >> Gonna be hard to do that
> >
> > OP might then take a look at editing the elf file directly. `objdump
> > --remove-section .symver blueriver_bitmap_streamer` should do the
> > trick.
>
> Why?

The OP wants to run his software.

Surely you have a better question than "Why," but I don't know what it is.

Jeff

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

On 2/27/24 09:23, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 8:34 AM Gremlin wrote:

On 2/27/24 08:27, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 5:52 AM Diego Luo （罗国雄） wrote:

Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to the
specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?

I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi
5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux”,
which is Debian based OS.

When running a SW I met the problem missing the required versions of GLIBCXX
and GLIBC, with the details below.

root@raspberrypi:/home/bitmap_overlap/linux-aarch64# ./blueriver_bitmap_streamer

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version
`GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version
`GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version
`GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)

root@raspberrypi:/home/bitmap_overlap/linux-aarch64#

Another option is to rebuild blueriver_bitmap_streamer. Before the
build, rip out that useless symbol versioning. All that symbol
versioning does is to cause a DoS and frustrate users.

You can find the ASM directives to rip out the versioning by grepping
for '.symver'. It will be in an ASM block.

https://info.semtech.com/blueriver-av-manager

The source:

https://semtech.my.salesforce.com/sfc/p/#E000JelG/a/RQ01m7Hx/ptDTNUqlZvD_8F_SbhjtoHaX9jOZ_fKxuauW0cZp5ag?utm_referrer=https%3A%2F%2Finfo.semtech.com%2F

Unable to Process Request
We couldn't access the content delivery.

This content has been deleted, doesn't exist, or can't be previewed.

Gonna be hard to do that

OP might then take a look at editing the elf file directly. `objdump
--remove-section .symver blueriver_bitmap_streamer` should do the
trick.

Jeff

Why?

Install a supported up to date OS and it should just work.
Raspian is an unsupported OS and has zero future.

--
Hindi madali ang maging ako

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Jeffrey Walton

On Tue, Feb 27, 2024 at 8:34 AM Gremlin  wrote:
>
> On 2/27/24 08:27, Jeffrey Walton wrote:
> > On Tue, Feb 27, 2024 at 5:52 AM Diego Luo （罗国雄）  wrote:
> >>
> >> Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to 
> >> the specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?
> >>
> >> I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
> >> 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 
> >> GNU/Linux”, which is Debian based OS.
> >>
> >> When running a SW I met the problem missing the required versions of 
> >> GLIBCXX and GLIBC, with the details below.
> >>
> >> root@raspberrypi:/home/bitmap_overlap/linux-aarch64# 
> >> ./blueriver_bitmap_streamer
> >>
> >> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: 
> >> version `GLIBCXX_3.4.29' not found (required by 
> >> ./blueriver_bitmap_streamer)
> >>
> >> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> >> `GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)
> >>
> >> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> >> `GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)
> >>
> >> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> >> `GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)
> >>
> >> root@raspberrypi:/home/bitmap_overlap/linux-aarch64#
> >
> > Another option is to rebuild blueriver_bitmap_streamer. Before the
> > build, rip out that useless symbol versioning. All that symbol
> > versioning does is to cause a DoS and frustrate users.
> >
> > You can find the ASM directives to rip out the versioning by grepping
> > for '.symver'. It will be in an ASM block.
>
> https://info.semtech.com/blueriver-av-manager
>
> The source:
>
> https://semtech.my.salesforce.com/sfc/p/#E000JelG/a/RQ01m7Hx/ptDTNUqlZvD_8F_SbhjtoHaX9jOZ_fKxuauW0cZp5ag?utm_referrer=https%3A%2F%2Finfo.semtech.com%2F
>
> Unable to Process Request
> We couldn't access the content delivery.
>
> This content has been deleted, doesn't exist, or can't be previewed.
>
> Gonna be hard to do that

OP might then take a look at editing the elf file directly. `objdump
--remove-section .symver blueriver_bitmap_streamer` should do the
trick.

Jeff

ARMv7 problematic? (was: How to upgrade the GLIBCXX and GLIBC to the specific version)

2024-02-27 Thread Stefan Monnier

> He is most likely using armv7 and that comes with its own issues, ie
> cpu type and floating point (hard/soft, neon and simd).  aarch64 much
> easier to build on.

I'm using Debian armhf here on various machines (most of them with ARMv7
CPUs but some one of them with an ARMv8 CPU (and kernel)).
I haven't encountered any particular problem (both in terms of using and
installing Debian and in terms of "manually" building software from
source) that seems related to ARMv7 vs ARMv8.


Stefan

Re: How to upgrade the GLIBCXX and GLIBC to the specific version


On 2/27/24 08:27, Jeffrey Walton wrote:

On Tue, Feb 27, 2024 at 5:52 AM Diego Luo （罗国雄）  wrote:


Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to the 
specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?

I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux”, 
which is Debian based OS.

When running a SW I met the problem missing the required versions of GLIBCXX 
and GLIBC, with the details below.

root@raspberrypi:/home/bitmap_overlap/linux-aarch64# ./blueriver_bitmap_streamer

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version 
`GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)

./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)

root@raspberrypi:/home/bitmap_overlap/linux-aarch64#


Another option is to rebuild blueriver_bitmap_streamer. Before the
build, rip out that useless symbol versioning. All that symbol
versioning does is to cause a DoS and frustrate users.

You can find the ASM directives to rip out the versioning by grepping
for '.symver'. It will be in an ASM block.

Jeff




https://info.semtech.com/blueriver-av-manager

The source:

https://semtech.my.salesforce.com/sfc/p/#E000JelG/a/RQ01m7Hx/ptDTNUqlZvD_8F_SbhjtoHaX9jOZ_fKxuauW0cZp5ag?utm_referrer=https%3A%2F%2Finfo.semtech.com%2F

Unable to Process Request
We couldn't access the content delivery.


This content has been deleted, doesn't exist, or can't be previewed.


Gonna be hard to do that

--
Hindi madali ang maging ako

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Jeffrey Walton

On Tue, Feb 27, 2024 at 5:52 AM Diego Luo （罗国雄）  wrote:
>
> Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to 
> the specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?
>
> I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
> 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 
> GNU/Linux”, which is Debian based OS.
>
> When running a SW I met the problem missing the required versions of GLIBCXX 
> and GLIBC, with the details below.
>
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64# 
> ./blueriver_bitmap_streamer
>
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version 
> `GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)
>
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)
>
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)
>
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)
>
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64#

Another option is to rebuild blueriver_bitmap_streamer. Before the
build, rip out that useless symbol versioning. All that symbol
versioning does is to cause a DoS and frustrate users.

You can find the ASM directives to rip out the versioning by grepping
for '.symver'. It will be in an ASM block.

Jeff

Re: How to upgrade the GLIBCXX and GLIBC to the specific version


On 2/27/24 08:15, Greg Wooledge wrote:

On Tue, Feb 27, 2024 at 08:08:47AM -0500, Gremlin wrote:


On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:

I am using the Raspberry Pi 4B with the Raspbian OS “Linux
raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44
BST 2022 aarch64 GNU/Linux”, which is Debian based OS.



He is most likely using armv7 and that comes with its own issues, ie cpu
type and floating point (hard/soft, neon and simd).  aarch64 much easier to
build on.


It looks like he's using aarch64.




You can not tell from that as he could be using a armv7 system and run a 
aarch64 kernel,  The foundation always run the 64 bit kernel on the 32 
bit system. The 32 bit installation script sets the flag in the 
config.txt file to run a 64 bit kernel on the 32 bit system on the rpi4.


From /boot/config.txt

# Run in 64-bit mode
arm_64bit=1

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Greg Wooledge

On Tue, Feb 27, 2024 at 08:08:47AM -0500, Gremlin wrote:

> > > On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:
> > > > I am using the Raspberry Pi 4B with the Raspbian OS “Linux
> > > > raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44
> > > > BST 2022 aarch64 GNU/Linux”, which is Debian based OS.

> He is most likely using armv7 and that comes with its own issues, ie cpu
> type and floating point (hard/soft, neon and simd).  aarch64 much easier to
> build on.

It looks like he's using aarch64.

Re: How to upgrade the GLIBCXX and GLIBC to the specific version


On 2/27/24 07:38, Arno Lehmann wrote:

Hi all,

Am 27.02.2024 um 13:19 schrieb Greg Wooledge:

On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:

Hi,

Would you pls help give tips about how to upgrade the GLIBCXX and 
GLIBC to the specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?


I am using the Raspberry Pi 4B with the Raspbian OS “Linux 
raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 
2022 aarch64 GNU/Linux”, which is Debian based OS.


That's a problem -- it is not Debian.


The new version for Rpi is and would not matter in his case as he is 
looking to update glibc.  That isn't platform pacific and doesn't matter.


Rpi 5:

uname -a
Linux scott 6.1.0-rpi8-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 
(2024-01-25) aarch64 GNU/Linux


cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;



Expecting insight here is a bit of a stretch. It would be much better to 
check with the actual distribution provider.


The provider is raspberry foundation and Raspian has been dis-continued.



Greg's advice about upgrading is demonstrating the versions for the 
x86_64 platform. This may or may not be directly applicable to your 
distribution. However, trying to upgrade something non-Debian with 
Debian packages may be exciting and provide great learning experience, 
but rarely is a smooth process.


sudo find /usr/lib -name '*libc.so*'
/usr/lib/aarch64-linux-gnu/libc.so.6
/usr/lib/aarch64-linux-gnu/libc.so

nm -D /usr/lib/aarch64-linux-gnu/libc.so.6 | grep 'A GLIBC_2\.3[0-9]'
 A GLIBC_2.30
 A GLIBC_2.31
 A GLIBC_2.32
 A GLIBC_2.33
 A GLIBC_2.34
 A GLIBC_2.35
 A GLIBC_2.36

sudo find /usr/lib -name '*libstdc++.so*'
/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
/usr/lib/gcc/aarch64-linux-gnu/12/libstdc++.so


nm -D /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30 | grep 'A 
GLIBCXX_3\.4\.[23][0-9]'

 A GLIBCXX_3.4.20
 A GLIBCXX_3.4.21
 A GLIBCXX_3.4.22
 A GLIBCXX_3.4.23
 A GLIBCXX_3.4.24
 A GLIBCXX_3.4.25
 A GLIBCXX_3.4.26
 A GLIBCXX_3.4.27
 A GLIBCXX_3.4.28
 A GLIBCXX_3.4.29
 A GLIBCXX_3.4.30



I would propose to head over to https://www.raspberrypi.com/software/ if 
you do not get very clear advice here.


Also, the actual software you want to use should be considered. If it's 
not packaged for your distribution, it's at least clear the packager 
does not guarantee anything. Rebuilding for your platform requires 
access to source code and (possibly) build environment. Suggestions or 
advice require you to disclose what you're actually looking at.


Good luck!

Arno



The correct solution is to download the latest and install that.
That is simple as rpi has an imager program that will d/l and install 
the image to the sdcard or USB drive.


Updating glibc can be difficult and may cause more breakage.
You should take that project lightly.

He is most likely using armv7 and that comes with its own issues, ie cpu 
type and floating point (hard/soft, neon and simd).  aarch64 much easier 
to build on.


Building custom OS for rpi since the rpi 1.  Will be building a custom 
OS for my rpi 4/5 servers and abandoning debian shortly, Desktop to follow.

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Arno Lehmann


Hi all,

Am 27.02.2024 um 13:19 schrieb Greg Wooledge:

On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:

Hi,

Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to the 
specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?

I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux”, 
which is Debian based OS.


That's a problem -- it is not Debian.

Expecting insight here is a bit of a stretch. It would be much better to 
check with the actual distribution provider.


Greg's advice about upgrading is demonstrating the versions for the 
x86_64 platform. This may or may not be directly applicable to your 
distribution. However, trying to upgrade something non-Debian with 
Debian packages may be exciting and provide great learning experience, 
but rarely is a smooth process.


I would propose to head over to https://www.raspberrypi.com/software/ if 
you do not get very clear advice here.


Also, the actual software you want to use should be considered. If it's 
not packaged for your distribution, it's at least clear the packager 
does not guarantee anything. Rebuilding for your platform requires 
access to source code and (possibly) build environment. Suggestions or 
advice require you to disclose what you're actually looking at.


Good luck!

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-27 Thread Greg Wooledge

On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:
> Hi,
> 
> Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to 
> the specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?
> 
> I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
> 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 
> GNU/Linux”, which is Debian based OS.
> When running a SW I met the problem missing the required versions of GLIBCXX 
> and GLIBC, with the details below.
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64# 
> ./blueriver_bitmap_streamer
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version 
> `GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64#

Your libc6 and libstdc++6 packages are too old to run this program.
Your choices are:

1) Find another, older, build of this program that's suitable for your
   system.

2) Recompile it yourself, if source code is available.

3) Find a substitute program.

4) Upgrade your operating system to a newer release.

Debian 12 (bookworm) should be new enough:

hobbit:~$ nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep 'A GLIBC_2\.3[0-9]'
 A GLIBC_2.30
 A GLIBC_2.31
 A GLIBC_2.32
 A GLIBC_2.33
 A GLIBC_2.34
 A GLIBC_2.35
 A GLIBC_2.36

hobbit:~$ nm -D /lib/x86_64-linux-gnu/libstdc++.so.6 | grep 'A 
GLIBCXX_3\.4\.[23][0-9]'
 A GLIBCXX_3.4.20
 A GLIBCXX_3.4.21
 A GLIBCXX_3.4.22
 A GLIBCXX_3.4.23
 A GLIBCXX_3.4.24
 A GLIBCXX_3.4.25
 A GLIBCXX_3.4.26
 A GLIBCXX_3.4.27
 A GLIBCXX_3.4.28
 A GLIBCXX_3.4.29
 A GLIBCXX_3.4.30

How to upgrade the GLIBCXX and GLIBC to the specific version

2024-02-26 Thread Diego Luo （罗国雄）

Hi,

Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to the 
specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?

I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux”, 
which is Debian based OS.
When running a SW I met the problem missing the required versions of GLIBCXX 
and GLIBC, with the details below.
root@raspberrypi:/home/bitmap_overlap/linux-aarch64# ./blueriver_bitmap_streamer
./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version 
`GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)
./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)
./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)
./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
`GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)
root@raspberrypi:/home/bitmap_overlap/linux-aarch64#

Thanks.

Best Regards
Diego


To view our privacy policy, including the types of personal information we 
collect, process and share, and the rights and options you have in this 
respect, see www.semtech.com/legal.

RE: Installing glibc-2.21 on debian-8

2015-07-06 Thread Arno Schuring

 Date: Mon, 6 Jul 2015 08:41:44 +0100
 From: zen75...@zen.co.uk

 On 06/07/15 06:07, Dhiraj Bhor wrote:
 Also wanted to know which are security bugs reported for glibc-2.19-18.
 Thanks for being patient.

 Information about current bugs in Debian packages can be found through
 the Bug Tracking System at https://bugs.debian.org/

 Upstream bug information for GNU libc can be found at
 https://sourceware.org/bugzilla/

There's also https://security-tracker.debian.org/tracker/source-package/glibc


Regards,
Arno

  

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w3889e0ba209b984db2aa49b8...@phx.gbl

Re: Installing glibc-2.21 on debian-8

2015-07-06 Thread Martin Read


On 06/07/15 06:07, Dhiraj Bhor wrote:

Also wanted to know which are security bugs reported for glibc-2.19-18.
Thanks for being patient.


Information about current bugs in Debian packages can be found through 
the Bug Tracking System at https://bugs.debian.org/


Upstream bug information for GNU libc can be found at 
https://sourceware.org/bugzilla/



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/559a3138.2090...@zen.co.uk

Re: Installing glibc-2.21 on debian-8

2015-07-06 Thread Dhiraj Bhor

On Mon, Jul 6, 2015 at 1:20 PM, Arno Schuring aelschur...@hotmail.com
wrote:

  Date: Mon, 6 Jul 2015 08:41:44 +0100
  From: zen75...@zen.co.uk
 
  On 06/07/15 06:07, Dhiraj Bhor wrote:
  Also wanted to know which are security bugs reported for glibc-2.19-18.
  Thanks for being patient.
 
  Information about current bugs in Debian packages can be found through
  the Bug Tracking System at https://bugs.debian.org/
 
  Upstream bug information for GNU libc can be found at
  https://sourceware.org/bugzilla/

 There's also
 https://security-tracker.debian.org/tracker/source-package/glibc


 Regards,
 Arno



 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive:
 https://lists.debian.org/dub124-w3889e0ba209b984db2aa49b8...@phx.gbl

 Thanks all for all the links and information.

Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-05 Thread Dhiraj Bhor

I read from https://wiki.debian.org/DebianExperimental link that installing
experimental package will functinaly break the system.
I want to know when experimental branch will become stable, Do i get any
page where this information already exist?

Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-05 Thread Dhiraj Bhor

On Mon, Jul 6, 2015 at 10:17 AM, Dhiraj Bhor dhirajbho...@gmail.com wrote:


 I read from https://wiki.debian.org/DebianExperimental link that
 installing experimental package will functinaly break the system.
 I want to know when experimental branch will become stable, Do i get any
 page where this information already exist?

Also wanted to know which are security bugs reported for glibc-2.19-18.
Thanks for being patient.

Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-05 Thread David Wright

Quoting Dhiraj Bhor (dhirajbho...@gmail.com):
 
 I read from https://wiki.debian.org/DebianExperimental link that installing
 experimental package will functinaly break the system.
 I want to know when experimental branch will become stable,

In a word, never.

 Do i get any page
 where this information already exist?

https://www.debian.org/doc/manuals/developers-reference/resources#s4.6.4
specifically 4.6.4.3

Cheers,
David.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150706051856.GA20837@alum

Installing glibc-2.21 on debian-8

Hi,

I have debian jessie (8.0) on virtual machine.
$] uname -a
Linux rdx86-ds7 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) i686 GNU/Linux

I need to install latest glibc (libc-2.21) on this machine.
My debian currently have libc-2.19
$] ls -lah /lib/i386-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Apr 14 17:21 /lib/i386-linux-gnu/libc.so.6 -
libc-2.19.so

I came across some documents and installed following packages as
prerequisites:
$] apt-get install linux-headers-$(uname -r)
$] apt-get install build-essentials

After this I have gcc-4.9.2
$] gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper
Target: i586-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch
--with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=i586-linux-gnu
--host=i586-linux-gnu --target=i586-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

$] cd /home/build/
$] wget http://ftp.gnu.org/gnu/glibc/glibc-2.21.tar.xz
$] tar xf glibc-2.21.tar.xz
$] mkdir glibc-test
$] cd glibc-test
$] ../glibc-2.21/configure --prefix=/usr
configure: error:
*** These critical programs are missing or too old: gawk
*** Check the INSTALL file for required versions.

$] apt-get install gawk
$] ../glibc-2.21/configure --prefix=/usr
$] echo $?
0
$] make
$] echo $?
0
$] make check

make  subdir=string -C string ..=../ tests
make[2]: Entering directory '/home/build/glibc-2.21/string'
gcc tester.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Werror -Winline
-Wno-error=undef -Wundef -Wwrite-strings -fmerge-all-constants
-frounding-math -g -Wstrict-prototypes   -Wa,-mtune=i686
 -I../include -I/home/build/glibc-test/string  -I/home/build/glibc-test
 -I../sysdeps/unix/sysv/linux/i386/i686  -I../sysdeps/i386/i686/nptl
 -I../sysdeps/unix/sysv/linux/i386  -I../sysdeps/unix/sysv/linux/x86
 -I../sysdeps/i386/nptl  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
 -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
 -I../sysdeps/unix/i386  -I../sysdeps/unix  -I../sysdeps/posix
 -I../sysdeps/i386/i686/fpu/multiarch  -I../sysdeps/i386/i686/fpu
 -I../sysdeps/i386/i686/multiarch  -I../sysdeps/i386/i686
 -I../sysdeps/i386/i486  -I../sysdeps/i386/fpu
 -I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/i386
 -I../sysdeps/x86  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/ldbl-96
 -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32
 -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.
-D_LIBC_REENTRANT -include /home/build/glibc-test/libc-modules.h
-DMODULE_NAME=nonlib -include ../include/libc-symbols.h   -o
/home/build/glibc-test/string/tester.o -MD -MP -MF
/home/build/glibc-test/string/tester.o.dt -MT
/home/build/glibc-test/string/tester.o
tester.c: In function ‘test_memset’:
tester.c:1313:10: error: ‘memset’ used with constant zero length parameter;
this could be due to transposed parameters [-Werror=memset-transposed-args]
   (void) memset(one+2, 'y', 0);
  ^
cc1: all warnings being treated as errors
../o-iterator.mk:9: recipe for target
'/home/build/glibc-test/string/tester.o' failed
make[2]: *** [/home/build/glibc-test/string/tester.o] Error 1
make[2]: Leaving directory '/home/build/glibc-2.21/string'
Makefile:213: recipe for target 'string/tests' failed
make[1]: *** [string/tests] Error 2
make[1]: Leaving directory '/home/build/glibc-2.21'
Makefile:9: recipe for target 'check' failed
make: *** [check] Error 2

I found comment#13 on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
Similar threads:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744

Please correct me if i am wrong
I have to install gcc-5.0 or above to install glibc-2.21?
Is there no way around?

Regards,
Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-03 Thread Sven Hartge

Dhiraj Bhor dhirajbho...@gmail.com wrote:

 $] wget http://ftp.gnu.org/gnu/glibc/glibc-2.21.tar.xz
 $] tar xf glibc-2.21.tar.xz
 $] mkdir glibc-test
 $] cd glibc-test
 $] ../glibc-2.21/configure --prefix=/usr

You do know that installing your own glibc over the one supplied by
Debian in the same path will most likely destroy your system.

If you do this to observe the effects of overwriting the system glibc
without proper prepartion, then all is fine.

If not, then please describe what you are trying to accomplish.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/15bo8a60i3...@mids.svenhartge.de

Re: Installing glibc-2.21 on debian-8

On Fri, Jul 3, 2015 at 3:12 PM, Sven Hartge s...@svenhartge.de wrote:

 Dhiraj Bhor dhirajbho...@gmail.com wrote:

  $] wget http://ftp.gnu.org/gnu/glibc/glibc-2.21.tar.xz
  $] tar xf glibc-2.21.tar.xz
  $] mkdir glibc-test
  $] cd glibc-test
  $] ../glibc-2.21/configure --prefix=/usr

 You do know that installing your own glibc over the one supplied by
 Debian in the same path will most likely destroy your system.

 If you do this to observe the effects of overwriting the system glibc
 without proper prepartion, then all is fine.

 If not, then please describe what you are trying to accomplish.

 Grüße,
 Sven.

 For my work requirement i need to build my project with latest glibc.
Yes i do understand that this can crash the system and i read some
documents but i am not getting success.
I have tried installing with --prefix=$HOME/objdir/ but no success. I have
got segmentation fault every time. (and reverted the machine to previous
working snapshot and tried again)

Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-03 Thread claude juif

Hi,

If you really need latest development tools, i suggest you to switch to
Fedora 22. (glibc-2.21-5 and gcc 5.1.1). It will be easier and faster than
trying to modify glibc stuff in Debian 8.

Regards,

2015-07-03 11:56 GMT+02:00 Dhiraj Bhor dhirajbho...@gmail.com:



 On Fri, Jul 3, 2015 at 3:12 PM, Sven Hartge s...@svenhartge.de wrote:

 Dhiraj Bhor dhirajbho...@gmail.com wrote:

  $] wget http://ftp.gnu.org/gnu/glibc/glibc-2.21.tar.xz
  $] tar xf glibc-2.21.tar.xz
  $] mkdir glibc-test
  $] cd glibc-test
  $] ../glibc-2.21/configure --prefix=/usr

 You do know that installing your own glibc over the one supplied by
 Debian in the same path will most likely destroy your system.

 If you do this to observe the effects of overwriting the system glibc
 without proper prepartion, then all is fine.

 If not, then please describe what you are trying to accomplish.

 Grüße,
 Sven.

 For my work requirement i need to build my project with latest glibc.
 Yes i do understand that this can crash the system and i read some
 documents but i am not getting success.
 I have tried installing with --prefix=$HOME/objdir/ but no success. I have
 got segmentation fault every time. (and reverted the machine to previous
 working snapshot and tried again)

 Dhiraj

Re: Installing glibc-2.21 on debian-8

On Fri, Jul 3, 2015 at 3:31 PM, claude juif claude.j...@gmail.com wrote:

 Hi,

 If you really need latest development tools, i suggest you to switch to
 Fedora 22. (glibc-2.21-5 and gcc 5.1.1). It will be easier and faster than
 trying to modify glibc stuff in Debian 8.

 Regards,

 I would like to but its a requirement and i have to do  it. No option.
May be if i can patch the glibc with all security patches will be enough
for me.

Dhiraj

Re: Installing glibc-2.21 on debian-8

2015-07-03 Thread Darac Marjal

On Fri, Jul 03, 2015 at 12:07:26PM +0530, Dhiraj Bhor wrote:
Hi,
I have debian jessie (8.0) on virtual machine.
$] uname -a
Linux rdx86-ds7 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) i686 GNU/Linux
I need to install latest glibc (libc-2.21) on this machine.

glibc 2.21 is in experimental. Read
https://wiki.debian.org/DebianExperimental to learn how to use
experimental.


-- 
For more information, please reread.


signature.asc
Description: Digital signature

RE: Installing glibc-2.21 on debian-8

2015-07-03 Thread Arno Schuring

 Date: Fri, 3 Jul 2015 15:37:03 +0530 
 From: dhirajbho...@gmail.com 
 On Fri, Jul 3, 2015 at 3:31 PM, claude juif  
 claude.j...@gmail.commailto:claude.j...@gmail.com wrote: 
 Hi, 

 If you really need latest development tools, i suggest you to switch to  
 Fedora 22. (glibc-2.21-5 and gcc 5.1.1). It will be easier and faster  
 than trying to modify glibc stuff in Debian 8. 

 Regards, 

 I would like to but its a requirement and i have to do  it. No option. 
 May be if i can patch the glibc with all security patches will be  
 enough for me. 

What exactly is the requirement? That you develop against latest libc
or that you deploy with latest libc? Because you mentioning security
patches makes me suspect it's the latter, in which case it's a seriously
bad idea to build your own. Are you going to subscribe to the CVE lists
and rebuild every security patch yourself? Have you factored the ongoing
maintenance cost of that in your project?

If it's only that your project needs to build against the latest glibc,
I recommend you start with an unstable buildroot (man debootstrap), and
install your latest libraries in there. You don't even need to develop
in the chroot, just develop on your own and run the integration tests in
the chroot.

Regards,
Arno

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/dub124-w397696c524f08c62438ac4b8...@phx.gbl

Re: Installing glibc-2.21 on debian-8

On Fri, Jul 3, 2015 at 3:46 PM, Arno Schuring aelschur...@hotmail.com
wrote:

  Date: Fri, 3 Jul 2015 15:37:03 +0530
  From: dhirajbho...@gmail.com
  On Fri, Jul 3, 2015 at 3:31 PM, claude juif
  claude.j...@gmail.commailto:claude.j...@gmail.com wrote:
  Hi,

  If you really need latest development tools, i suggest you to switch to
  Fedora 22. (glibc-2.21-5 and gcc 5.1.1). It will be easier and faster
  than trying to modify glibc stuff in Debian 8.

  Regards,

  I would like to but its a requirement and i have to do  it. No option.
  May be if i can patch the glibc with all security patches will be
  enough for me.

 What exactly is the requirement? That you develop against latest libc
 or that you deploy with latest libc? Because you mentioning security
 patches makes me suspect it's the latter, in which case it's a seriously
 bad idea to build your own. Are you going to subscribe to the CVE lists
 and rebuild every security patch yourself? Have you factored the ongoing
 maintenance cost of that in your project?

 If it's only that your project needs to build against the latest glibc,
 I recommend you start with an unstable buildroot (man debootstrap), and
 install your latest libraries in there. You don't even need to develop
 in the chroot, just develop on your own and run the integration tests in
 the chroot.

 Regards,
 Arno

 Thanks @Darac. i am new to this, But what i understood is debian system
must have glibc which is shipped as with installation media and better i
don't mess with it.
I will try the experimental branch.
@Amo: Your suggestion about ROI is acceptable and thanks for reminding the
cost effectiveness for the same.

Ksplice Re: NeedRestart et mode non interactif [Re: Faille critique découverte dans GLIBC]

2015-02-17 Thread yamo'

Salut,

Frédéric MASSOT a écrit le 04/02/2015 15:00 :
 Pour la mise à jour du noyau il faut rebooter, voir dans certain cas on 
 peut utiliser ksplice.

C'est la première fois que j'en entend parler.

Est-ce qu'en pratique ça fonctionne bien?
La page la plus pratique que j'ai trouvé est :
https://wiki.ubuntu.com/Ksplice

Ça pourrait m'intéresser pour des Debian et CentOS.

Sur Debian, c'est disponible pour squeeze et wheezy :
http://ksplice.oracle.com/legacy#supported-kernels

-- 
Stéphane

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mbutkm$cf4$1...@usenet.pasdenom.info

Résolu : suite vulnérabilité glibc updates

2015-02-05 Thread Pierre TOUZEAU

Merci à François et Bernard.

Incroyable, je n'avais pas la ligne security dans sources.list et de
fait  apt-cache policy libc6  ne proposait pas la version 7u7 en candidat.

C'est corrigé et cela fonctionne.
Merci
Pierre


Le 05/02/2015 12:25, Francois Lafont a écrit :
 Bonjour,

 Le 05/02/2015 12:16, Pierre TOUZEAU a écrit :
 Sous Wheezy 7.8, j'ai fait le test du message ci-dessous : Vulnerable
 J'ai vérifié la lib avec ldd --version  :  Debian EGLIBC 2.13-38+deb7u6
 et non Debian EGLIBC 2.13-38+deb7u7 qui serait secure

 apt-get clean
 apt-get update
 apt-get upgrade
 reboot

 et...  c'est pareil !
 J'ai recompilé le test (c'est inutile je pense mais sait on jamais...) :
 vulnerable

 et la version de glibc n'a pas varié...

 Je comprends pas...
 Et si tu fais ça ?

 apt-get update  apt-get install libc6

 Tu as bien http://security.debian.org/ dans ton sources.list ?


-- 
Pro. Signature

Pierre Touzeau

--
Chargé de mission  /  Préfecture de region Basse-Normandie
SGAR/rue Daniel HUET/14038 CAEN CEDEX/Tel: +33 231 306 306
pierre.touz...@basse-normandie.pref.gouv.fr / Fax: ... 564
--

Re: suite vulnérabilité glibc updates

2015-02-05 Thread Francois Lafont

Bonjour,

Le 05/02/2015 12:16, Pierre TOUZEAU a écrit :
 Sous Wheezy 7.8, j'ai fait le test du message ci-dessous : Vulnerable
 J'ai vérifié la lib avec ldd --version  :  Debian EGLIBC 2.13-38+deb7u6
 et non Debian EGLIBC 2.13-38+deb7u7 qui serait secure
 
 apt-get clean
 apt-get update
 apt-get upgrade
 reboot
 
 et...  c'est pareil !
 J'ai recompilé le test (c'est inutile je pense mais sait on jamais...) :
 vulnerable
 
 et la version de glibc n'a pas varié...
 
 Je comprends pas...

Et si tu fais ça ?

apt-get update  apt-get install libc6

Tu as bien http://security.debian.org/ dans ton sources.list ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mavjvk$um1$1...@ger.gmane.org

Re: suite vulnérabilité glibc updates

2015-02-05 Thread Bernard Isambert


Le 05/02/2015 12:16, Pierre TOUZEAU a écrit :

  Sous Wheezy 7.8, j'ai fait le test du message ci-dessous : Vulnerable
J'ai vérifié la lib avec ldd --version  :  Debian EGLIBC 2.13-38+deb7u6
et non Debian EGLIBC 2.13-38+deb7u7 qui serait secure

apt-get clean

aucun rapoport avec ce que vous voulez faire


apt-get update
apt-get upgrade


Que dit apt-cache policy libc6 ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d35806.1020...@taranig.net

Re: Re: suite vulnérabilité glibc updates

2015-02-05 Thread Pierre TOUZEAU

Sous Wheezy 7.8, j'ai fait le test du message ci-dessous : Vulnerable
J'ai vérifié la lib avec ldd --version  :  Debian EGLIBC 2.13-38+deb7u6
et non Debian EGLIBC 2.13-38+deb7u7 qui serait secure

apt-get clean
apt-get update
apt-get upgrade
reboot

et...  c'est pareil !
J'ai recompilé le test (c'est inutile je pense mais sait on jamais...) :
vulnerable

et la version de glibc n'a pas varié...

Je comprends pas...


Pierre


Le 04/02/2015 17:37, yamo' a écrit :
 Salut,
 Le 04/02/2015 16:40, cont...@baal.fr a écrit :
 bonjour la liste,

 suite à la découverte d'une vulnérabilité dans glibc OvH propose un
 script utilisable sur toutes les distro linux .


 Il y a cette page qui donne un script avec son code source :
 http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck


-- 
Pro. Signature

Pierre Touzeau

--
Chargé de mission  /  Préfecture de region Basse-Normandie
SGAR/rue Daniel HUET/14038 CAEN CEDEX/Tel: +33 231 306 306
pierre.touz...@basse-normandie.pref.gouv.fr / Fax: ... 564
--

Re: suite vulnérabilité glibc updates

2015-02-04 Thread yamo'


Salut,
Le 04/02/2015 16:40, cont...@baal.fr a écrit :

bonjour la liste,

suite à la découverte d'une vulnérabilité dans glibc OvH propose un
script utilisable sur toutes les distro linux .



Il y a cette page qui donne un script avec son code source : 
http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck


--
Stéphane

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mathso$b2q$1...@usenet.pasdenom.info

Re: NeedRestart et mode non interactif [Re: Faille critique découverte dans GLIBC]

2015-02-04 Thread David BERCOT

Bonsoir,

Le Wed, 04 Feb 2015 14:56:00 +0100,
Frédéric MASSOT frede...@juliana-multimedia.com a écrit :
 Le 03/02/2015 14:57, David BERCOT a écrit :
  Bonjour,
 
  Le Wed, 28 Jan 2015 15:50:11 +0100,
  Frédéric MASSOT frede...@juliana-multimedia.com a écrit :
  [...]
  Sur les distrib plus récentes (wheezy-backports, jessie, sid)  tu
  peux utiliser la commande needrestart, du paquet du même nom, qui
  liste les daemons à redémarrer et les redémarre si tu le souhaite.
 
  Une fois le paquet needrestart installé, il est lancé à la fin
  des installations par apt.
 
  J'utilise en effet needrestart sur mon ordi personnel et il
  fonctionne parfaitement.
 
  Maintenant, sachant qu'il est lancé automatiquement à la fin de la
  mise à jour, je me demandais comment cela se passait dans le cas
  d'un lancement batch de mise à jour [j'avoue que je n'ai pas encore
  testé] ? Est-ce paramétrable ? Peut-on lui dire, dans ce cas, de ne
  rien faire ou, au contraire, de relancer tous les services qui ont
  besoin de l'être, voire, enfin, de tout relancer si nécessaire (y
  compris le système complet en cas de MAJ du noyau par exemple) ?
 
 Qu'est-ce que tu appelles un lancement batch ? un système de
 déploiement ?

Je parlais d'une mise à jour automatique programmée par un cron.
Dans un environnement géré avec validation initiale des nouveaux
paquets, on programme les mises à jour automatiques sur un ensemble de
serveurs.
Après, il faut juste gérer éventuellement les choses (services, voire
noyau) à redémarrer...

 D'après la page de manuel il y a un mode batch, la config est dans ce 
 dossier /etc/needrestart/.
 
 /etc/needrestart/
 ├── conf.d
 │   └── README.needrestart
 ├── hook.d
 │   ├── 10-dpkg
 │   ├── 20-rpm
 │   └── 90-none
 └── needrestart.conf 
 
 À la fin de la mise à jour, comme avec un apt-get dist-upgrade, 
 needrestart affiche une petite fenêtre avec la liste des daemons à 
 relancer. Il y a une case à cocher en face de chacun d'eux, certain
 sont déjà sélectionnés d'autres non. Tu peux valider les
 re-démarrages des daemons ou ne rien faire.
 
 needrestart est lancé par ce fichier 
 /etc/apt/apt.conf.d/99needrestart, mais tu peux lancer la commande 
 needrestart à la main quand tu veux.
 
 Pour la mise à jour du noyau il faut rebooter, voir dans certain cas
 on peut utiliser ksplice.

OK. Je vais regarder la doc à l'occasion (c'est d'ailleurs ce que
j'aurais du faire avant de poser ma question ;-)).

Merci.

David.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150204230804.29775a40@debian-david

Re: NeedRestart et mode non interactif [Re: Faille critique découverte dans GLIBC]

2015-02-04 Thread Frédéric MASSOT


Le 03/02/2015 14:57, David BERCOT a écrit :

Bonjour,

Le Wed, 28 Jan 2015 15:50:11 +0100,
Frédéric MASSOT frede...@juliana-multimedia.com a écrit :
[...]

Sur les distrib plus récentes (wheezy-backports, jessie, sid)  tu
peux utiliser la commande needrestart, du paquet du même nom, qui
liste les daemons à redémarrer et les redémarre si tu le souhaite.

Une fois le paquet needrestart installé, il est lancé à la fin des
installations par apt.


J'utilise en effet needrestart sur mon ordi personnel et il fonctionne
parfaitement.

Maintenant, sachant qu'il est lancé automatiquement à la fin de la mise
à jour, je me demandais comment cela se passait dans le cas d'un
lancement batch de mise à jour [j'avoue que je n'ai pas encore testé] ?
Est-ce paramétrable ? Peut-on lui dire, dans ce cas, de ne rien faire
ou, au contraire, de relancer tous les services qui ont besoin de
l'être, voire, enfin, de tout relancer si nécessaire (y compris le
système complet en cas de MAJ du noyau par exemple) ?


Qu'est-ce que tu appelles un lancement batch ? un système de déploiement ?

D'après la page de manuel il y a un mode batch, la config est dans ce 
dossier /etc/needrestart/.


/etc/needrestart/
├── conf.d
│   └── README.needrestart
├── hook.d
│   ├── 10-dpkg
│   ├── 20-rpm
│   └── 90-none
└── needrestart.conf


À la fin de la mise à jour, comme avec un apt-get dist-upgrade, 
needrestart affiche une petite fenêtre avec la liste des daemons à 
relancer. Il y a une case à cocher en face de chacun d'eux, certain sont 
déjà sélectionnés d'autres non. Tu peux valider les re-démarrages des 
daemons ou ne rien faire.


needrestart est lancé par ce fichier 
/etc/apt/apt.conf.d/99needrestart, mais tu peux lancer la commande 
needrestart à la main quand tu veux.


Pour la mise à jour du noyau il faut rebooter, voir dans certain cas on 
peut utiliser ksplice.



--
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d224f0.1010...@juliana-multimedia.com

suite vulnérabilité glibc updates

2015-02-04 Thread cont...@baal.fr


bonjour la liste,

suite à la découverte d'une vulnérabilité dans glibc OvH propose un 
script utilisable sur toutes les distro linux .



# wget ftp://ftp.ovh.net/made-in-ovh/security/GHOST.c
# gcc -o GHOST GHOST.c
# ./GHOST

la réponse est instantanée.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d23c11.9050...@baal.fr

NeedRestart et mode non interactif [Re: Faille critique découverte dans GLIBC]

2015-02-03 Thread David BERCOT

Bonjour,

Le Wed, 28 Jan 2015 15:50:11 +0100,
Frédéric MASSOT frede...@juliana-multimedia.com a écrit :
[...]
 Sur les distrib plus récentes (wheezy-backports, jessie, sid)  tu
 peux utiliser la commande needrestart, du paquet du même nom, qui
 liste les daemons à redémarrer et les redémarre si tu le souhaite.
 
 Une fois le paquet needrestart installé, il est lancé à la fin des 
 installations par apt.

J'utilise en effet needrestart sur mon ordi personnel et il fonctionne
parfaitement.

Maintenant, sachant qu'il est lancé automatiquement à la fin de la mise
à jour, je me demandais comment cela se passait dans le cas d'un
lancement batch de mise à jour [j'avoue que je n'ai pas encore testé] ?
Est-ce paramétrable ? Peut-on lui dire, dans ce cas, de ne rien faire
ou, au contraire, de relancer tous les services qui ont besoin de
l'être, voire, enfin, de tout relancer si nécessaire (y compris le
système complet en cas de MAJ du noyau par exemple) ?

Merci.

David.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150203145719.0367e7c7@debian-david

Re: Faille critique découverte dans GLIBC

2015-02-03 Thread Vincent Lefevre

On 2015-01-30 13:57:11 +0100, Francois Lafont wrote:
 Le 30/01/2015 01:55, Vincent Lefevre a écrit :
 
  Exemple avec un petit script zsh:
  
  zmodload zsh/stat
[...]
 Merci pour cet exemple. On ne doit pas avoir la même commande
 stat exactement car sur ma Debian Wheezy la sortie de stat donne
 ça :
[...]

J'ai utilisé le builtin stat de zsh (cf le zmodload, et c'est pour
ça que je parlais de script zsh), qui permet de faire un stat sur
un descripteur de fichier. C'est nécessaire après le rm.
Alternativement, on doit pouvoir utiliser /proc/$$/fd/num
avec un stat standard, mais pas sûr que ça fonctionne de manière
fiable (il y a peut-être des effets secondaires).

 Avec la commande stat, on voit le nombre de hardlink du
 fichier mais on ne voit pas le nombre de processus qui
 font référence à ce fichier (parce qu'ils ont ouvert
 le-dit fichier). Existe-t-il une commande pour voir ce
 nombre là ?

Sébastien a indiqué fuser, mais il ne prend pas un fd en entrée,
au cas où le fichier a été ouvert par ton processus, puis unlinké.
Là encore, /proc/pid/fd/num est peut-être la solution.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150203133243.ga32...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

2015-02-02 Thread Sébastien NOBILI

Bonjour,

Voilà, je m'absente quelques jours et vous continuez sans moi !
Très intéressante cette discussion, merci à tous.

Le samedi 31 janvier 2015 à  9:57, mrr a écrit :
 Essaye lsof. Avec ou sans argument si tu veux une _longue_ liste. Y'a
 aussi une autre commande de ce gout dont je me rappelle plus là.

Ça ne serait pas la commande « fuser » par hasard ?

« fuser - identify processes using files or sockets »

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150202102038.gd13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

2015-02-01 Thread Francois Lafont

Le 31/01/2015 20:13, Pascal Hambourg a écrit :
 Francois Lafont a écrit :

 Et donc, si j'ai bien suivi ce qui suit dans tes explications,
 (...)
 J'ai bon ?
 
 Oui.
 
 Ok, on est d'accord que dans le cas du deuxième paragraphe, le
 fichier existe toujours mais il complètement inaccessible via
 l'arborescence du file system ? (ce qui est, je trouve, pas commun).
 
 On peut mettre le phénomène en évidence par accident par exemple
 lorsqu'un supprime de gros fichiers de log pour libérer de l'espace et
 qu'on se rend compte que l'espace libre n'a pas augmenté, car les
 fichiers de logs sont restés ouverts par le processus écrivain. Il faut
 arrêter ou redémarrer ce processus pour que l'espace soit libéré (et que
 le processus écrive dans un nouveau fichier de log).

Ok, merci Pascal pour ta réponse.
Bien que, pour une bonne partie, ce fil ait été un peu HS (désolé pour ça),
j'y ai appris beaucoup de choses.

À+

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/malct6$lul$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-31 Thread mrr


On 30/01/2015 14:00, Francois Lafont wrote:

Avec la commande stat, on voit le nombre de hardlink du
fichier mais on ne voit pas le nombre de processus qui
font référence à ce fichier (parce qu'ils ont ouvert
le-dit fichier). Existe-t-il une commande pour voir ce
nombre là ?



Essaye lsof. Avec ou sans argument si tu veux une _longue_ liste. Y'a 
aussi une autre commande de ce gout dont je me rappelle plus là.


Bon, tout est expliqué, là j'ai appris du coup, merci les gars!
Et pour la petite histoire, à propos de vim et parce que personne ne m'a 
répondu et bien c'est la même explication que pour les fichiers en cours 
d’exécution remplacés lors d'une mise à jour.
Vim travaille sur une copie dans son cache et lorsque l'on commande une 
écriture disque un nouveau fichier écrase l'ancien (donc nouvel inode). 
On n'a pas touché à l'ancien qui continue à être exécuté par exemple 
dans le cas d'un service mis à jour.
Il me reste à déterminer si un service tout neuf qui utilise la libc se 
servira de la nouvelle (cela me semble logique) tant que tous n'auront 
pas été stoppé afin que toute trace de l'ancienne ait disparue.
Bref, quelqu'un a remarqué qu'on s'éloignait bien du thème de la liste 
et ce n'est pas ici que je vous demanderai comment fonctionne l'édition 
de lien dynamique ou autres joyeusetés (mémoire virtuelle...).


--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54cc9912$0$3034$426a3...@news.free.fr

Re: Glibc 2.15 not found?

2015-01-31 Thread Reco

 Hi.

On Sat, 31 Jan 2015 11:35:54 +0100
Håkon Alstadheim ha...@alstadheim.priv.no wrote:

 On 29. jan. 2015 20:12, Stephen wrote:
  On 01/29/2015 11:08 AM, Sven Hartge wrote:
  If you are a novice user, the glibc is the _last_ thing you want to mess
  with.
 
  Grüße,
  Sven.
 
  Hmm, that is scary. I don't want to break anything. I am quite 
  adventurous but I can handle not playing VV until Jessie releases 
  if that is the case.
 
 
 
 How would lxc be in this use-case? Specifically how would a container 
 access a graphics display ?

1) Running VV via 'ssh -X'. Straightforward, and requires doing
something else with the sound.

2) Running a VNC server inside the container. Unsuitable for games
IMO, but straightforward.

3) Running a separate X server inside the container. Requires allowing
the container to use at least /dev/input/*, /dev/dri/*, and, of
course, a tty (see [1] as an example). Leaves the sound question open
too.

[1] http://mraw.org/blog/2011/04/05/Running_X_from_LXC

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150131204920.dc2c5c564a6ce13ebc570...@gmail.com

Re: Faille critique découverte dans GLIBC

2015-01-31 Thread Pascal Hambourg

Francois Lafont a écrit :
 
 Et donc, si j'ai bien suivi ce qui suit dans tes explications,
(...)
 J'ai bon ?

Oui.

 Ok, on est d'accord que dans le cas du deuxième paragraphe, le
 fichier existe toujours mais il complètement inaccessible via
 l'arborescence du file system ? (ce qui est, je trouve, pas commun).

On peut mettre le phénomène en évidence par accident par exemple
lorsqu'un supprime de gros fichiers de log pour libérer de l'espace et
qu'on se rend compte que l'espace libre n'a pas augmenté, car les
fichiers de logs sont restés ouverts par le processus écrivain. Il faut
arrêter ou redémarrer ce processus pour que l'espace soit libéré (et que
le processus écrive dans un nouveau fichier de log).

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54cd2970.8070...@plouf.fr.eu.org

Re: Glibc 2.15 not found?

2015-01-31 Thread Cindy-Sue Causey

On 1/29/15, Ric Moore wayward4...@gmail.com wrote:
On 01/29/2015 02:08 PM, Sven Hartge wrote:
Stephen skaldicpo...@gmail.com wrote:

I wouldn't mind building it by hand, I'm trying to get more 'hands on'
(pun completely intended) with Debian. I am just a novice user though
so I have a very faint clue what your talking about...

If you are a novice user, the glibc is the _last_ thing you want to mess
with.

Jessie is completely stable, according to my experience. You will be
better off just doing a fresh install, after backing up personal files.

I was thinking the exact same thing, that Jessie has proved stable
*for me*. That's a disclaimer intended to mean everyone's own
experience can and will vary.. Jessie's in fact *so stable* for me,
I'm actually bored. I debootstrapped Sid couple hours ago and am
just running through my inbox before attempting to set Sid up tonight.

After years of doing these kinds of things every possible way wrong,
my most likely path now in a situation like this would be to go the
route of installing the whole new newer release (upgrade) if that is
the only place the desired package is found. With installing a whole
new unified release, everything is intended to work together rather
than, for example, us users trying to shove one of Jessie's new square
pegs into a potentially non-existent old round hole in Wheezy.

And I would be doing the above *KNOWING* Jessie is still labeled as
*testing* which means not guaranteed stable even though many of us are
finding it works well right now.

Good luck whichever route you go!

Cindy :)

--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* Installing Sid?! Got a fire extinguisher handy just in case? CHECK! *

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cao1p-kag47t8abswgsowpx1x4af8vzb--zgbnqektegqxyx...@mail.gmail.com

Re: Glibc 2.15 not found?

2015-01-31 Thread Håkon Alstadheim


On 29. jan. 2015 20:12, Stephen wrote:

On 01/29/2015 11:08 AM, Sven Hartge wrote:

If you are a novice user, the glibc is the _last_ thing you want to mess
with.

Grüße,
Sven.

Hmm, that is scary. I don't want to break anything. I am quite 
adventurous but I can handle not playing VV until Jessie releases 
if that is the case.





How would lxc be in this use-case? Specifically how would a container 
access a graphics display ?


Generally containers would be a great relief to have when playing with 
unsafe s^H computing :-) .




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ccb00a.40...@alstadheim.priv.no

Re: Faille critique découverte dans GLIBC

2015-01-30 Thread Francois Lafont

Le 30/01/2015 01:55, Vincent Lefevre a écrit :

 Exemple avec un petit script zsh:
 
 zmodload zsh/stat
 echo foo  tmp-file
 stat tmp-file | grep -E '^(inode|nlink) '
 exec  tmp-file
 stat -f 0 | grep -E '^(inode|nlink) '
 rm tmp-file
 stat -f 0 | grep -E '^(inode|nlink) '
 cat
 
 J'obtiens:
 
 inode   4940899
 nlink   1
 inode   4940899
 nlink   1
 inode   4940899
 nlink   0
 foo

Merci pour cet exemple. On ne doit pas avoir la même commande
stat exactement car sur ma Debian Wheezy la sortie de stat donne
ça :

# stat tmp-file 
  File: `tmp-file'
  Size: 4   Blocks: 8  IO Block: 4096   regular file
Device: 801h/2049d  Inode: 131580  Links: 1
Access: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Access: 2015-01-30 13:47:52.480110199 +0100
Modify: 2015-01-30 13:47:52.476110343 +0100
Change: 2015-01-30 13:47:52.476110343 +0100
 Birth: -

De plus l'option -f ne correspond apparemment pas à ce que
fait l'option -f chez toi (chez moi -f ou --file-system
« display file system status instead of file status »).

Mais peu importe, j'ai compris l'idée de ton exemple.

Avec la commande stat, on voit le nombre de hardlink du
fichier mais on ne voit pas le nombre de processus qui
font référence à ce fichier (parce qu'ils ont ouvert
le-dit fichier). Existe-t-il une commande pour voir ce
nombre là ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mafv33$4fs$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-30 Thread Francois Lafont

Le 30/01/2015 01:45, Vincent Lefevre a écrit :

 Tu parles bien de la mis à jour d'une lib ?
 Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode.
 Par exemple, j'ai ça :

 ~$ touch /tmp/foo.so
 ~$ touch /tmp/foo.so.new-version

 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

 # Je considère la commande ci-dessous comme une màj du fichier foo.so
 ~$ cp /tmp/foo.so.new-version /tmp/foo.so

 # Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version
 
 Mais une mise à jour ne fait pas un cp. Un cp va modifier un
 fichier si la destination existe, pas créer un nouveau fichier.

Ok et une màj, ça fait quoi alors ? Ça fait globalement ceci ?

rm foo.so  cp /working/dir/de/apt/foo.so /chemin/de/foo.so

Auquel cas effectivement l'inode associé au fichier foo.so
n'est plus le même.

Et donc, si j'ai bien suivi ce qui suit dans tes explications,
l'ancienne version de foo.so n'est plus accessible via
l'arborescence du file system mais l'inode vers l'ancien fichier
foo.so existe toujours dans la table des inodes du fs et donc
la zone de disque où se trouve encore l'ancienne version de
foo.so existe toujours et elle est encore non disponible en
écriture tant qu'il existera des processus qui font référence
à cet inode parce (qu'ils ont ouvert l'ancienne version du fichier
foo.so). Quand tous ces processus seront morts, l'inode pointant
vers l'ancienne versio de foo.so sera supprimé de la table des
inodes et la zone de disque (celle où se trouve l'ancienne version
de foo.so) sera à nouveau disponible (bref l'ancienne version de
foo.so est définitivement perdue).

J'ai bon ?

 Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.

 qui contient la nouvelle version du fichier, mais l'inode
 originel reste présent 

 Présent où ça ? Dans les « attributs » des processus en cours ?
 
 Présent sur le disque (et référencé par les processus).

Ok.

 tant qu'il reste des liens, donc tant qu'il n'est
 pas fermé par les processus qui l'ont ouvert.

 Mais durant cette période transitoire où il reste encore des
 processus qui ont ouvert un fichier situé sur une zone A du
 disque, zone pointée par cet « ancien » inode, qu'en est-il
 de cette zone A du disque ? Est-elle disponible ou non ?
 
 Non, elle n'est toujours pas disponible. Le fichier existe
 toujours. Cf la page man unlink(2):
 
   unlink() deletes a name from the filesystem.  If that name was the last
   link to a file and no processes have the file open, the file is deleted
   and the space it was using is made available for reuse.
 
   If  the  name  was the last link to a file but any processes still have
   the file open, the file will remain in existence until  the  last  file
   descriptor referring to it is closed.
 
   If the name referred to a symbolic link, the link is removed.

Ok, on est d'accord que dans le cas du deuxième paragraphe, le
fichier existe toujours mais il complètement inaccessible via
l'arborescence du file system ? (ce qui est, je trouve, pas commun).

 Si je comprends bien d'un côté cette zone n'est plus accessible via
 l'arborescence du filesystem car l'ancien inode n'existe plus. Du
 coup, cette zone du disque serait libre en quelques sortes ?
 
 Non, l'ancien inode existe toujours (je suppose qu'un processus
 qui a le fichier ouvert peut toujours faire un fstat sur le
 descripteur de fichier pour obtenir le numéro d'inode).

Ok, merci pour ces explications Vincent. :)

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mafspi$sne$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

On 2015-01-28 23:16:48 +0100, Bernard Isambert wrote:
 Le 28/01/2015 20:59, Philippe Deleval a écrit :
 C'est une blague? A mon avis, tout programmeur utilisant la fonction de
 bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
 il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
 ct, n), le petit n fait la différence.

 Et ceux qui créé la fonction strcpy sont des criminels qui devraient être
 guillotinés sur le champ. Heureusement, Zorro est arrivé et a sauvé
 l'informatique...

Faut voir l'historique: strcpy date de l'origine du langage C,
à un temps où on ne se préoccupait pas trop des problèmes de
sécurité.

Maintenant, la fonction strcpy devrait peut-être prendre le même
chemin que gets.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129103012.gb8...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

On 2015-01-28 20:59:50 +0100, Philippe Deleval wrote:
 C'est une blague? A mon avis, tout programmeur utilisant la fonction de
 bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où il
 travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s, ct, n),
 le petit n fait la différence.

Enfin, strncpy n'est pas vraiment safe non plus. Un problème est
que si le n est trop petit, le buffer n'est plus forcément terminé
par un \0, ce qui peut être en soi un trou de sécurité: si on
copie la chaîne contenue dans le buffer, cela peut donc copier
des données au-delà du buffer, et on se retrouve donc avec des
bugs du type heartbleed. La vraie solution est d'avoir une fonction
qui fait un abort() quand le n est trop petit... et si le serveur
est critique, on n'écrit pas en C.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129105433.gc8...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread mrr


Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?


J'ajouterais, dans un souci d'échange et de discussion, que le reboot ne 
me semble pas si important que cela (aie, je prend un risque en disant 
cela), pourquoi?
Les fichiers qui correspondent aux processus exécutés sur un système 
Linux sont protégés en écriture, petit rappel:

$ cat  read_bloquant.c  FIN

# include stdio.h

int main (void)
{
read (0, NULL, sizeof(int));

/* En gros on exécute un appel système bloquant, on lit depuis l'entrée 
standard, en général la console, NULL parce qu'on s'en fout du résultat 
et le sizeof parce que ça fait plus cool qu'un 4 ou un 8 (et portable). 
Donc tant qu'on n'entre pas un caractère (dac, un nombre (cela dit, 
c'est du C, c'est pareil pour lui, chez moi il en mange 4 donc int = 4 
octets, moins si caractère en dehors ascii et si console en UTF-8 par 
ex) et qu'on n'appuie pas sur Entrée le programme attend */


exit (0);
}

FIN

Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
Donc on compile et on exécute:

$ gcc read_bloquant.c -o read_bloquant
$ ./read_bloquant

Ça y est, le processus attend.
Sur une autre console :

$ kate read_bloquant
(ou gedit, mousepad etc.)

Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
Et possible lorsque le programme n'est pas exécuté.

Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de souci 
particulier, virtualbox (qui n'était pas en exécution) s'est recompilé 
son module, 2-3 petits trucs et c'était bon.
Ce que j'en conclus, c'est que sur mon système la mise à jour n'a 
remplacé aucun fichier en cours d'utilisation donc que le reboot n'est 
peut-être pas indispensable.



Toutefois, juste pour être sûr et si j'étais admin je viderais tout ce 
qui est buffer/cache avant la mise à jour et également après tant qu'à 
faire:

# echo 3  /proc/sys/vm/drop_caches

Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram), je 
tuerais quelque processus après avoir exécuté:

# echo 0  /proc/sys/vm/swappiness

Attention tout de même à ne pas exécuter cela sur un pc avec très peu de 
mémoire mais de toute façon je suis même pas sûr que cette dernière 
ligne aurait de l'effet dans ce cas.


Une dernière chose:
Un programme peut être lié à une ABI de la libc de façon statique ou 
dynamique.


Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre 
autres grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 
qui est appelé chez moi), aucun problème tant que le programme utilise 
un cache bien mis à jour (ce qui est normalement le cas mais c'est t'on 
jamais d'où les 2 dernières commandes).


Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai 
pas vérifié), alors là un reboot n'y fera rien, il faudra recompiler le 
paquet, c'est d'ailleurs un des principaux désavantage des librairies 
statiques (avec la quantité d'espace mémoire utilisée, l'avantage étant 
un programme très légèrement plus rapide).


Voilà pour mes petites réflexion, s'il y a des erreurs de logique merci 
de me corriger.


Cordialement/Bises...

--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Dominique Asselineau

mrr wrote on Thu, Jan 29, 2015 at 02:17:32PM +0100
 Ah, au fait, petite question. Après les commandes ci-dessus,
 faut-il que je fasse un reboot ?
 
 J'ajouterais, dans un souci d'échange et de discussion, que le
 reboot ne me semble pas si important que cela (aie, je prend un
 risque en disant cela), pourquoi?

Il faut juste penser à prévenir les utilisateurs suffisamment à
l'avance pour éviter de leur casser la baraque.

Dominique

 Les fichiers qui correspondent aux processus exécutés sur un système
 Linux sont protégés en écriture, petit rappel:
 $ cat  read_bloquant.c  FIN
 
 # include stdio.h
 
 int main (void)
 {
 read (0, NULL, sizeof(int));
 
 /* En gros on exécute un appel système bloquant, on lit depuis
 l'entrée standard, en général la console, NULL parce qu'on s'en fout
 du résultat et le sizeof parce que ça fait plus cool qu'un 4 ou un 8
 (et portable). Donc tant qu'on n'entre pas un caractère (dac, un
 nombre (cela dit, c'est du C, c'est pareil pour lui, chez moi il
 en mange 4 donc int = 4 octets, moins si caractère en dehors ascii
 et si console en UTF-8 par ex) et qu'on n'appuie pas sur Entrée le
 programme attend */
 
 exit (0);
 }
 
 FIN
 
 Désolé si ça fait un peu cours et pour tout ceux qui savent déjà tout ça!
 Donc on compile et on exécute:
 
 $ gcc read_bloquant.c -o read_bloquant
 $ ./read_bloquant
 
 Ça y est, le processus attend.
 Sur une autre console :
 
 $ kate read_bloquant
 (ou gedit, mousepad etc.)
 
 Impossible de sauvegarder les modifs (on peut avec vim, allez savoir!).
 Et possible lorsque le programme n'est pas exécuté.
 
 Lorsque j'ai mis à jour la libc sur ma wheezy je n'ai pas eu de
 souci particulier, virtualbox (qui n'était pas en exécution) s'est
 recompilé son module, 2-3 petits trucs et c'était bon.
 Ce que j'en conclus, c'est que sur mon système la mise à jour n'a
 remplacé aucun fichier en cours d'utilisation donc que le reboot
 n'est peut-être pas indispensable.
 
 
 Toutefois, juste pour être sûr et si j'étais admin je viderais tout
 ce qui est buffer/cache avant la mise à jour et également après tant
 qu'à faire:
 # echo 3  /proc/sys/vm/drop_caches
 
 Et si ça swappe (c'est pas dit avec tout ces ordi à 8+ Gb de ram),
 je tuerais quelque processus après avoir exécuté:
 # echo 0  /proc/sys/vm/swappiness
 
 Attention tout de même à ne pas exécuter cela sur un pc avec très
 peu de mémoire mais de toute façon je suis même pas sûr que cette
 dernière ligne aurait de l'effet dans ce cas.
 
 Une dernière chose:
 Un programme peut être lié à une ABI de la libc de façon statique ou
 dynamique.
 
 Si c'est dynamique comme l'appel à read ci-dessus (on peux voir
 entre autres grâce à strace que c'est
 /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est appelé chez moi),
 aucun problème tant que le programme utilise un cache bien mis à
 jour (ce qui est normalement le cas mais c'est t'on jamais d'où les
 2 dernières commandes).
 
 Si c'est statique (avec la libc ce doit être rare voire inexistant,
 j'ai pas vérifié), alors là un reboot n'y fera rien, il faudra
 recompiler le paquet, c'est d'ailleurs un des principaux désavantage
 des librairies statiques (avec la quantité d'espace mémoire
 utilisée, l'avantage étant un programme très légèrement plus
 rapide).
 
 Voilà pour mes petites réflexion, s'il y a des erreurs de logique
 merci de me corriger.
 
 Cordialement/Bises...
 
 --
 mrr
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists
 
 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/54ca32ea$0$3190$426a7...@news.free.fr
 

-- 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129134917.gb11...@telecom-paristech.fr

Glibc 2.15 not found?

2015-01-29 Thread Stephen

I'm trying to run the game VV on my system but whenever I try and 
launch it I get the following error: ./x86/vv.x86: 
/lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found 
(required by ./x86/libSDL2-2.0.so.0)


I tried looking for glibc 2.15 in the software repository but could find 
no such package. How do I satisfy this dependency then?


-many thanks, Stephen


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54ca790d.4050...@gmail.com

Re: Glibc 2.15 not found?

2015-01-29 Thread Sven Hartge

Stephen skaldicpo...@gmail.com wrote:

 I'm trying to run the game VV on my system but whenever I try and
 launch it I get the following error: ./x86/vv.x86:
 /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not
 found (required by ./x86/libSDL2-2.0.so.0)

 I tried looking for glibc 2.15 in the software repository but could
 find no such package. How do I satisfy this dependency then?

You need at least Debian Jessie/Testing für a glibc new enough.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7bbgj80va...@mids.svenhartge.de

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Sébastien NOBILI

Bonjour,

J'ai bien aimé le passage en C, ça m'a rappelé de (trop) vieux souvenirs ;-)


Le jeudi 29 janvier 2015 à 14:17, mrr a écrit :
 Un programme peut être lié à une ABI de la libc de façon statique ou
 dynamique.
 
 Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
 grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
 appelé chez moi), aucun problème tant que le programme utilise un cache bien
 mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
 dernières commandes).

Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.

 Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
 vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
 c'est d'ailleurs un des principaux désavantage des librairies statiques
 (avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
 très légèrement plus rapide).

Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.

Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150129140619.gb13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread andre_debian

On Thursday 29 January 2015 14:17:32 mrr wrote:
  Ah, au fait, petite question. Après les commandes ci-dessus,
  faut-il que je fasse un reboot ?

 J'ajouterais, dans un souci d'échange et de discussion, que le reboot ne
 me semble pas si important que cela (aie, je prend un risque en disant
 cela), pourquoi?
 Les fichiers qui correspondent aux processus exécutés sur un système
 Linux sont protégés en écriture, petit rappel:  [cut]

Sous Wheezy, j'avais bien updaté glibc6,
recompilé ghosttest.c et avais : Vulnerable

J'ai fait un reboot = Not vulnerable.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501291521.26865.andre_deb...@numericable.fr

Re: Glibc 2.15 not found?

2015-01-29 Thread Florent Peterschmitt

On 01/29/2015 07:31 PM, Sven Hartge wrote:
 Stephen skaldicpo...@gmail.com wrote:
 
 I'm trying to run the game VV on my system but whenever I try and
 launch it I get the following error: ./x86/vv.x86:
 /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not
 found (required by ./x86/libSDL2-2.0.so.0)
 
 I tried looking for glibc 2.15 in the software repository but could
 find no such package. How do I satisfy this dependency then?
 
 You need at least Debian Jessie/Testing für a glibc new enough.
 
 Grüße,
 Sven.
 

Or a custom glibc installed in an isolated prefix, then playing with
LD_LIBRARY_PATH to load the new glibc.

Or if you don't want to build it by hand, you may do something tricky:
extracting the Jessie package by hand in, again, an isolated prefix. But
i'm not that sure it would work.



signature.asc
Description: OpenPGP digital signature

Re: Glibc 2.15 not found?

2015-01-29 Thread Stephen


On 01/29/2015 11:08 AM, Sven Hartge wrote:

If you are a novice user, the glibc is the _last_ thing you want to mess
with.

Grüße,
Sven.

Hmm, that is scary. I don't want to break anything. I am quite 
adventurous but I can handle not playing VV until Jessie releases if 
that is the case.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54ca8604.5060...@gmail.com

Re: Glibc 2.15 not found?

2015-01-29 Thread Stephen



On 01/29/2015 10:46 AM, Florent Peterschmitt wrote:
Or a custom glibc installed in an isolated prefix, then playing with 
LD_LIBRARY_PATH to load the new glibc.


Or if you don't want to build it by hand, you may do something tricky: 
extracting the Jessie package by hand in, again, an isolated prefix. 
But i'm not that sure it would work.


I wouldn't mind building it by hand, I'm trying to get more 'hands on' 
(pun completely intended) with Debian. I am just a novice user though so 
I have a very faint clue what your talking about...



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54ca830d.3040...@gmail.com

Re: Glibc 2.15 not found?

2015-01-29 Thread Florent Peterschmitt

On 01/29/2015 07:59 PM, Stephen wrote:
 
 On 01/29/2015 10:46 AM, Florent Peterschmitt wrote:
 Or a custom glibc installed in an isolated prefix, then playing with
 LD_LIBRARY_PATH to load the new glibc.
 
 Or if you don't want to build it by hand, you may do something tricky:
 extracting the Jessie package by hand in, again, an isolated prefix.
 But i'm not that sure it would work.
 
 I wouldn't mind building it by hand, I'm trying to get more 'hands on'
 (pun completely intended) with Debian. I am just a novice user though so
 I have a very faint clue what your talking about...

I understand.

Well, you don't have much choices. Force-install a newer glibc in the
base system will break your entire system, so here are the options:

 * install another version of Debian containing the required glibc version

 * install another distro if you don't want to use unstable softwares.
if you want to stay on a debian-like and are a novice, can I suggest you
Ubuntu or LinuxMint?

 * build your glibc by hand (see LFS pages[0], they can be helpful) but
install files (not configuration) in, say, /opt/glibc-version. Then to
use you'll need to play with some environment variables. At least you
know how to run a program from command line, so env variables are just
the next step :-)

 * download the newer, packaged, version of glibc from unstable or
testing Debian, extract it by hand and put files in a prefix, like
before. Then use env vars an pray for it to work.



[0]
http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html



signature.asc
Description: OpenPGP digital signature

Re: Glibc 2.15 not found?

2015-01-29 Thread Sven Hartge

Stephen skaldicpo...@gmail.com wrote:
 On 01/29/2015 10:46 AM, Florent Peterschmitt wrote:

 Or a custom glibc installed in an isolated prefix, then playing with
 LD_LIBRARY_PATH to load the new glibc.

 Or if you don't want to build it by hand, you may do something
 tricky: extracting the Jessie package by hand in, again, an isolated
 prefix.  But i'm not that sure it would work.

 I wouldn't mind building it by hand, I'm trying to get more 'hands on'
 (pun completely intended) with Debian. I am just a novice user though
 so I have a very faint clue what your talking about...

If you are a novice user, the glibc is the _last_ thing you want to mess
with.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8bbglcnva...@mids.svenhartge.de

Re: Glibc 2.15 not found?

2015-01-29 Thread Sven Hartge

Stephen skaldicpo...@gmail.com wrote:
 On 01/29/2015 11:08 AM, Sven Hartge wrote:

 If you are a novice user, the glibc is the _last_ thing you want to
 mess with.

 Hmm, that is scary. I don't want to break anything. I am quite
 adventurous but I can handle not playing VV until Jessie releases
 if that is the case.

The glibc (or libc6) is _the_ central system library. Mess with it and
you summon the sixth circle of hell right to your room :)

Doing things with the glibc while inexperienced results nearly always in
a reinstall of your system.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/9bbgmlava...@mids.svenhartge.de

Re: Glibc 2.15 not found?

2015-01-29 Thread Ric Moore


On 01/29/2015 02:08 PM, Sven Hartge wrote:

Stephen skaldicpo...@gmail.com wrote:

On 01/29/2015 10:46 AM, Florent Peterschmitt wrote:



Or a custom glibc installed in an isolated prefix, then playing with
LD_LIBRARY_PATH to load the new glibc.



Or if you don't want to build it by hand, you may do something
tricky: extracting the Jessie package by hand in, again, an isolated
prefix.  But i'm not that sure it would work.



I wouldn't mind building it by hand, I'm trying to get more 'hands on'
(pun completely intended) with Debian. I am just a novice user though
so I have a very faint clue what your talking about...


If you are a novice user, the glibc is the _last_ thing you want to mess
with.


Jessie is completely stable, according to my experience. You will be 
better off just doing a fresh install, after backing up personal files. 
:) Ric




--
My father, Victor Moore (Vic) used to say:
There are two Great Sins in the world...
..the Sin of Ignorance, and the Sin of Stupidity.
Only the former may be overcome. R.I.P. Dad.
Linux user# 44256


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54ca8dc0.4010...@gmail.com

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Philippe Deleval


Le 28/01/2015 23:16, Bernard Isambert a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

Bonjour à tous

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.

Cordialement


Philippe Deleval

Et ceux qui créé la fonction strcpy sont des criminels qui devraient 
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a 
sauvé l'informatique...


Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le 
système qu'ils écrivaient et le langage qu'ils concevaient auraient une 
telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C 
est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui 
était plus ou moins bon. strcpy peut encore être utilisé sans danger par 
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des 
chaînes qu'il manipule, je pnese que c'était la vocation première. Mais 
lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire!


Cordialement

Philippe Deleval (et non zorro, je ne sais pas monter à cheval!)

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca9395.2070...@wanadoo.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread mrr


Salut Seb,


Si c'est dynamique comme l'appel à read ci-dessus (on peux voir entre autres
grâce à strace que c'est /lib/i386-linux-gnu/i686/cmov/libc.so.6 qui est
appelé chez moi), aucun problème tant que le programme utilise un cache bien
mis à jour (ce qui est normalement le cas mais c'est t'on jamais d'où les 2
dernières commandes).


Oups, ça c'est de l'erreur de syntaxe (de logique aussi si on veut):

s/c'est/sait



Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il faudra me
corriger) que la bibliothèque dynamique est chargée au démarrage du programme.
Chacun des appels système sera donc fait selon la version installée à ce
moment-là. Si on met à jour la bibliothèque en cours d'exécution, le programme
ne profitera donc pas des corrections.


Je vois, au 1er appel la librairie serait mappée en mémoire puis en 
quelque sorte détachée de sa source, à savoir le fichier sur le disque. 
Tu dois avoir raison, cela aurait également le mérite d'expliquer ma 
1ère remarque, l'accès en écriture sur un fichier en cours d'exécution 
(bon, processus, dac mais on se comprend).

Et ça expliquerait aussi le résultat d'André (message suivant).

Par contre, ce qui me gène un peu c'est que cela signifierait que chaque 
processus en cours d'exécution aurait sa propre copie en mémoire.


Ou il y a une autre possibilité de comprendre ta phrase qui me convient 
mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée 
pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout 
le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et 
alors elle serait déchargée.


De toute façon je vais essayer genre pour le fun =
- créer un .so qui affiche Version initiale.
- lancer un programme qui appelle .so puis qui se bloque.
- modifier le .so pour qu'il affiche Version modifiée.
- reprendre l'exécution.
Et tant qu'à faire, lancer le programme 2 fois, avant et après modif.

Si je fais ça rapidement je vous poste le résultat.

Au passage, si quelqu'un pouvait m'expliquer le comportement de vim (en 
une phrase, je sais que c'est pas le sujet initial)?



Si c'est statique (avec la libc ce doit être rare voire inexistant, j'ai pas
vérifié), alors là un reboot n'y fera rien, il faudra recompiler le paquet,
c'est d'ailleurs un des principaux désavantage des librairies statiques
(avec la quantité d'espace mémoire utilisée, l'avantage étant un programme
très légèrement plus rapide).


Oui, pour les liens statiques, aucun impact sans passer par une recompilation.
C'est donc hors-champ.

Un autre avantage des liens statiques, c'est le coté transportable du binaire,
tu peux le lancer sur une machine qui ne dispose pas de toutes les bibliothèques
nécessaires (puisque le programme « embarque » tous les bouts de bibliothèques
dont il a besoin).


Exact, bien vu!
Je crois au passage que c'est bien plus utilisé sur Windows, ça règle 
les problèmes de versions et on sait vraiment avec quoi on travaille.
Linux est plus ambitieux mais parallèlement (et on en parlait récemment 
sur un autre thread) cela augmente la complexité du système de dépendances.



Seb



@ Sébastien (message précédent, je vais pas alourdir le fil de 3 
messages juste pour ça): je crois avoir bien précisé que je n'étais pas 
sûr de moi et à aucun moment j'ai déconseillé le reboot (qui est 
manifestement utile d'après les réponses des uns et des autres).


Update:

- En réfléchissant aux autres librairies que fournit la glibc j'ai 
oublié de penser que c'est elle même qui fournit le chargeur de lien 
dynamique (via /lib/i386-linux-gnu/ld-2.13.so sur mon système) qui est 
lui même un objet partagé. Bon, même combat, il faut bien d'une façon ou 
d'une autre que le nouveau entre en action. Et d'une façon ou d'une 
autre c'est l'ancien qui charge le nouveau afin que ce dernier l'écrase. 
Ouais, du coup, _reboot_ ça me parle plus là.


- De la page man de ld.so et à la section BOGUES:
	Actuellement, ld.so ne peut pas enlever un lien existant pour chercher 
des bibliothèques compatibles ou plus récentes.

Ça revient à ce que tu disais Seb.

Allez, bonne nuit tout le monde.

--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54ca99a9$0$3295$426a7...@news.free.fr

Re: Glibc 2.15 not found?

2015-01-29 Thread Siard

Stephen wrote:
 I don't want to break anything. I am quite adventurous but I can
 handle not playing VV until Jessie releases

I just tried the Windows demo with this command:

$ wine ./vv_demo.exe

No need to install anything, it seems to run fine.
So, until Jessie releases, running vv.exe with wine could be an
option.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150129220104.1dc20bb8.shiems...@kpnplanet.nl

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread mrr


On 29/01/2015 21:10, Philippe Deleval wrote:

Le 28/01/2015 23:16, Bernard Isambert a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

Bonjour à tous

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave! Il y a à côté strncpy(char *strncpy (s,
ct, n), le petit n fait la différence.

Cordialement


Philippe Deleval


Et ceux qui créé la fonction strcpy sont des criminels qui devraient
être guillotinés sur le champ. Heureusement, Zorro est arrivé et a
sauvé l'informatique...


Ceux qui ont créé strcpy n'étaient sans doute pas conscients que le
système qu'ils écrivaient et le langage qu'ils concevaient auraient une
telle fortune, avaient-ils prévu Internet? Après tout, ma source sur C
est signée Kernighan-Ritchie. C'est l'expérience qui a dégagé ce qui
était plus ou moins bon. strcpy peut encore être utilisé sans danger par
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des
chaînes qu'il manipule, je pnese que c'était la vocation première. Mais
lire par strcpy une chaîne qui vient d'ailleurs, c'est un risque notoire!


Un des trucs qui me plaît dans linux (ok, la libc c'est pas que linux, 
je sais) donc ce qui me plait c'est la liberté qu'on te donne, y compris 
la liberté de faire une bêtise.


Essayez (ou pas en fait) le fameux rm -rf / et vous aurez droit à un 
gentil message qui vous préviendra que c'est dangereux.


Je suis nostalgique, avant on pouvait détruire son système en paix :)


Cordialement

Philippe Deleval (et non zorro, je ne sais pas monter à cheval!)




--
--
mrr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caa1da$0$3066$426a7...@news.free.fr

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Pascal Hambourg

mrr a écrit :
 
 Dans ce cas, il me semble (et je peux donc me tromper, dans ce cas, il 
 faudra me
 corriger) que la bibliothèque dynamique est chargée au démarrage du 
 programme.
 Chacun des appels système sera donc fait selon la version installée à ce
 moment-là. Si on met à jour la bibliothèque en cours d'exécution, le 
 programme
 ne profitera donc pas des corrections.

Et c'est bien pour cela qu'il faut redémarrer les processus utilisant un
exécutable (bibliothèque ou autre) mis à jour.

 Je vois, au 1er appel la librairie serait mappée en mémoire puis en 

Oui.

 quelque sorte détachée de sa source, à savoir le fichier sur le disque.

Non, elle reste liée au fichier. C'est le principe du mapping. Même
chose pour l'exécutable d'un programme qui tourne.

 Par contre, ce qui me gène un peu c'est que cela signifierait que chaque 
 processus en cours d'exécution aurait sa propre copie en mémoire.

Non, pas forcément, tant que la copie n'est pas modifiée. Ensuite seules
les pages éventuellement modifiées par un processus font l'objet d'une
copie séparée dans la mémoire virtuelle de ce processus.

 Ou il y a une autre possibilité de comprendre ta phrase qui me convient 
 mieux, c'est qu'à chaque fois qu'une bibliothèque partagée est appelée 
 pour la *1ère* fois, elle serait mappée dans l'espace virtuel pour tout 
 le monde jusqu'à ce qu'il n'y ait plus aucun processus qui l'utilise et 
 alors elle serait déchargée.

Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
l'inode correspondant, au même titre que les liens durs dans les
répertoires. La mise à jour fait pointer le nom du fichier vers un
nouvel inode qui contient la nouvelle version du fichier, mais l'inode
originel reste présent tant qu'il reste des liens, donc tant qu'il n'est
pas fermé par les processus qui l'ont ouvert.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caa225.5040...@plouf.fr.eu.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Bernard Isambert



trolldi (en avance)

Le 29/01/2015 21:09, Philippe Deleval a écrit :

Le 28/01/2015 20:59, Philippe Deleval a écrit :

C'est une blague? A mon avis, tout programmeur utilisant la fonction de
bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la boîte où
il travaille pour faute grave!



strcpy peut encore être utilisé sans danger par
un programmeur qui sait ce qu'il fait et maîtrise la longiueur des
chaînes qu'il manipule,


Conclusion évidente : vous voulez renvoyer pour faute grave un 
programmeur qui sait ce qu'il fait !


Excusez-moi, je n'ai pas pu m'empêcher de faire le rapprochement entre 
vos deux phrases ! C'était trop tentant !


/trolldi


--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54caab9e.3090...@taranig.net

Re: Faille critique découverte dans GLIBC

On 2015-01-30 01:45:47 +0100, Vincent Lefevre wrote:
 On 2015-01-30 00:30:29 +0100, Francois Lafont wrote:
  Si je comprends bien d'un côté cette zone n'est plus accessible via
  l'arborescence du filesystem car l'ancien inode n'existe plus. Du
  coup, cette zone du disque serait libre en quelques sortes ?
 
 Non, l'ancien inode existe toujours (je suppose qu'un processus
 qui a le fichier ouvert peut toujours faire un fstat sur le
 descripteur de fichier pour obtenir le numéro d'inode).

Exemple avec un petit script zsh:

zmodload zsh/stat
echo foo  tmp-file
stat tmp-file | grep -E '^(inode|nlink) '
exec  tmp-file
stat -f 0 | grep -E '^(inode|nlink) '
rm tmp-file
stat -f 0 | grep -E '^(inode|nlink) '
cat

J'obtiens:

inode   4940899
nlink   1
inode   4940899
nlink   1
inode   4940899
nlink   0
foo

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130005530.ga16...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

On 2015-01-30 00:30:29 +0100, Francois Lafont wrote:
 Le 29/01/2015 22:12, Pascal Hambourg a écrit :
  Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
  l'inode correspondant, au même titre que les liens durs dans les
  répertoires. La mise à jour fait pointer le nom du fichier vers un
  nouvel inode 
 
 Tu parles bien de la mis à jour d'une lib ?
 Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode.
 Par exemple, j'ai ça :
 
 ~$ touch /tmp/foo.so
 ~$ touch /tmp/foo.so.new-version
 
 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version
 
 # Je considère la commande ci-dessous comme une màj du fichier foo.so
 ~$ cp /tmp/foo.so.new-version /tmp/foo.so
 
 # Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
 ~$ ls -i /tmp/foo.so*
 523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

Mais une mise à jour ne fait pas un cp. Un cp va modifier un
fichier si la destination existe, pas créer un nouveau fichier.

 Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.
 
  qui contient la nouvelle version du fichier, mais l'inode
  originel reste présent 
 
 Présent où ça ? Dans les « attributs » des processus en cours ?

Présent sur le disque (et référencé par les processus).

  tant qu'il reste des liens, donc tant qu'il n'est
  pas fermé par les processus qui l'ont ouvert.
 
 Mais durant cette période transitoire où il reste encore des
 processus qui ont ouvert un fichier situé sur une zone A du
 disque, zone pointée par cet « ancien » inode, qu'en est-il
 de cette zone A du disque ? Est-elle disponible ou non ?

Non, elle n'est toujours pas disponible. Le fichier existe
toujours. Cf la page man unlink(2):

  unlink() deletes a name from the filesystem.  If that name was the last
  link to a file and no processes have the file open, the file is deleted
  and the space it was using is made available for reuse.

  If  the  name  was the last link to a file but any processes still have
  the file open, the file will remain in existence until  the  last  file
  descriptor referring to it is closed.

  If the name referred to a symbolic link, the link is removed.

 Si je comprends bien d'un côté cette zone n'est plus accessible via
 l'arborescence du filesystem car l'ancien inode n'existe plus. Du
 coup, cette zone du disque serait libre en quelques sortes ?

Non, l'ancien inode existe toujours (je suppose qu'un processus
qui a le fichier ouvert peut toujours faire un fstat sur le
descripteur de fichier pour obtenir le numéro d'inode).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150130004547.gb14...@xvii.vinc17.org

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Vincent Bernat

 ❦ 28 janvier 2015 20:59 +0100, Philippe Deleval philippe.dele...@wanadoo.fr :

 C'est une blague? A mon avis, tout programmeur utilisant la fonction
 de bibliothèque C char *strcpy (s, ct) devrait être renvoyé de la
 boîte où il travaille pour faute grave! Il y a à côté strncpy(char
 *strncpy (s, ct, n), le petit n fait la différence.

Faire strncpy(hostname, name, strlen(name) + 1) est tout à fait
inutile. Le problème n'est pas le strcpy, mais la taille allouée pour la
structure incluant hostname qui était trop petite.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Faille critique découverte dans GLIBC

2015-01-29 Thread Francois Lafont

On sort un peu (beaucoup) du sujet de cette liste mais
ça m'intéresse alors du coup j'aurais quelques questions
si c'est possible.

Le 29/01/2015 22:12, Pascal Hambourg a écrit :

 Il y a de ça. Chaque ouverture d'un fichier compte pour un lien vers
 l'inode correspondant, au même titre que les liens durs dans les
 répertoires. La mise à jour fait pointer le nom du fichier vers un
 nouvel inode 

Tu parles bien de la mis à jour d'une lib ?
Dans ce cas, je ne comprends pas trop ce que tu veux dire par nouvel inode.
Par exemple, j'ai ça :

~$ touch /tmp/foo.so
~$ touch /tmp/foo.so.new-version

~$ ls -i /tmp/foo.so*
523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

# Je considère la commande ci-dessous comme une màj du fichier foo.so
~$ cp /tmp/foo.so.new-version /tmp/foo.so

# Et je constate que le numéro d'inode de foo.so n'a pas bougé ?
~$ ls -i /tmp/foo.so*
523294 /tmp/foo.so  523295 /tmp/foo.so.new-version

Du coup, j'ai pas dû comprendre quelque chose dans ta phrase.

 qui contient la nouvelle version du fichier, mais l'inode
 originel reste présent 

Présent où ça ? Dans les « attributs » des processus en cours ?
(Pour le terme « attributs », désolé je ne connais pas le bon vocabulaire.)

 tant qu'il reste des liens, donc tant qu'il n'est
 pas fermé par les processus qui l'ont ouvert.

Mais durant cette période transitoire où il reste encore des
processus qui ont ouvert un fichier situé sur une zone A du
disque, zone pointée par cet « ancien » inode, qu'en est-il
de cette zone A du disque ? Est-elle disponible ou non ?

Si je comprends bien d'un côté cette zone n'est plus accessible via
l'arborescence du filesystem car l'ancien inode n'existe plus. Du
coup, cette zone du disque serait libre en quelques sortes ?

Mais d'un autre côté, on peut imaginer que le système se doit
d'interdire toute écriture au niveau de cette zone du disque
sans quoi les processus ouverts pourraient lire alors absolument
n'importe quoi au niveau de cette zone et donc finalement cette
zone mémoire n'est donc pas complètement disponible encore ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maefqg$o2t$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Sébastien NOBILI

Bonjour,

Le mercredi 28 janvier 2015 à 14:43, Francois Lafont a écrit :
 Le 28/01/2015 14:34, Francois Lafont a écrit :
  echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free 
   /etc/apt/sources.list.d/squeeze-lts.list
  apt-get update
  apt-get upgrade
 
 Ah, au fait, petite question. Après les commandes ci-dessus,
 faut-il que je fasse un reboot ?
 
 Si j'ai bien compris, si un daemon dépend d'une lib, il faut
 redémarrer le-dit daemon après la mise à jour de la-dite lib.
 Seulement j'ai cru comprendre que globalement, quasiment tous
 les daemons (sous Debian) dépendent in fine de la glibc et
 qu'au final un reboot est globalement nécessaire. Bref, j'ai
 lu je ne sais plus où que l'idée selon laquelle seule la
 màj du noyau nécessitait un reboot était inexacte et que le
 reboot était également nécessaire pour la màj de la glic.
 
 Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
 Merci d'avance.

Loin de moi l'idée de me considérer comme tel…

Il y a justement une discussion à ce sujet en ce moment sur debian-security [1].
Tous les programmes qui utilisent de la bibliothèque mise à jour doivent être
redémarrés. On doit donc redémarrer les services qui l'utilisent.

Dans le cas de la libc, ça devient problématique car _tous_ les programmes du
système l'utilisent. Il faut donc redémarrer _tous_ les programmes actuellement
en fonctionnement.

Deux approches :
- tu les identifies un par un et tu les redémarres un par un (et tu ne fais
  rien d'autre de ta journée);
- tu rebootes et c'est réglé en quelques minutes.

1: https://lists.debian.org/debian-security/2015/01/msg00035.html

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150128135116.gd13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit :

 Non, seul squeeze-lts évolue encore.
 
 Ok, merci pour la réponse.

 En même temps ma question était sans doute un peu bête, car le dépôt LTS
 perdrait tout son sens si le dépôt squeeze évoluait encore. ;)
 
 Pourrait-on avoir le mode opératoire sous Debian,

Sous Squeeze ?
Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using

Perso, je ne me suis pas embêté :

echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free  
/etc/apt/sources.list.d/squeeze-lts.list
apt-get update
apt-get upgrade

 sans faire ce que propose ce site :
 www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
 à savoir # apt-get dist-upgrade

Perso, j'avoue que je l'utilise quotidiennement cette commande
et je n'ai jamais eu de souci. Ai-je tort ?

Si j'ai bien compris ce que dit la page man, avec upgrade aucune
chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
ça peut arriver.

Évidemment si je mets des dépôts de la distribution n+1 dans les
sources.list alors là un dist-upgrade peut faire des dégats mais
sinon j'ai l'impression que dans 99% des cas un upgrade et un
dist-upgrade font au final la même chose.

De toute façon, si tu veux être prudent, tu fais un upgrade et
puis voilà (en plus même avec un dist-upgrade, tu jettes un œil
sur les modifications que souhaite faire la commande avant de
confirmer).

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maaohh$fco$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Sébastien NOBILI

Le mercredi 28 janvier 2015 à 14:34, Francois Lafont a écrit :
Le 28/01/2015 14:19, andre_deb...@numericable.fr a écrit :
sans faire ce que propose ce site :
www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
à savoir # apt-get dist-upgrade

Perso, j'avoue que je l'utilise quotidiennement cette commande
et je n'ai jamais eu de souci. Ai-je tort ?

Je l'utilise également au quotidien (plutôt au gré des mises à jour qui
arrivent) et sans aucun souci depuis plusieurs années.

Si j'ai bien compris ce que dit la page man, avec upgrade aucune
chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
ça peut arriver.

C'est exactement ça, « upgrade » ne fera que ce qui ne nécessite aucun ajout ni
aucune suppression alors que « dist-upgrade » mettra tout à niveau même si ça
nécessite ajout ou suppression.

Évidemment si je mets des dépôts de la distribution n+1 dans les
sources.list alors là un dist-upgrade peut faire des dégats mais
sinon j'ai l'impression que dans 99% des cas un upgrade et un
dist-upgrade font au final la même chose.

C'est exactement ça.

Attention toutefois.

On peut référencer la branche Debian dans le sources.list par son nom
(« squeeze », « wheezy », « jessie ») ou bien par son type (« stable »,
« testing »).

Si on référence le type, alors un « dist-upgrade » conduit au passage d'une
branche à la suivante dès la publication.

Si on veut vraiment maîtriser son système, mieux vaut référencer la branche par
son nom.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150128135530.ge13...@sebian.nob900.homeip.net

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:55, Sébastien NOBILI a écrit :

 Attention toutefois.
 
 On peut référencer la branche Debian dans le sources.list par son nom
 (« squeeze », « wheezy », « jessie ») ou bien par son type (« stable »,
 « testing »).
 
 Si on référence le type, alors un « dist-upgrade » conduit au passage d'une
 branche à la suivante dès la publication.
 
 Si on veut vraiment maîtriser son système, mieux vaut référencer la branche 
 par
 son nom.

Oh oui, perso j'ai toujours mis le nom sans penser au départ à ce
que tu décris mais je connais des gens qui se sont pris un upgrade
de distribution dans la figure comme ça. :)

Merci pour ta réponse.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maaqln$ksa$1...@ger.gmane.org

Re: glibc bug - time to patch

2015-01-28 Thread Lisi Reisz

On Wednesday 28 January 2015 13:25:20 i...@thargoid.co.uk wrote:
 On 2015-01-28 12:27, Peter Viskup wrote:
  before considering downtimes and patching activities on production
  servers
  read these:
 
  https://www.debian.org/security/2015/dsa-3142
  http://seclists.org/oss-sec/2015/q1/283
 
  especially the second link mention network-facing software which is not
  vulnerable due to proper sanitization out of glibc.

 Indeed, however you will notice that the list on the second link does
 not contain exim, the default SMTP server software for debian. This was
 used for proof-of-concept code.

 http://seclists.org/oss-sec/2015/q1/274

So Wheezy users who use Exim are at risk? But it surely then follows that 
Wheezy users who do not use Exim, or even have it installed, are not at risk?

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281427.18269.lisi.re...@gmail.com

Re: glibc bug - time to patch

2015-01-28 Thread iain


On 2015-01-28 12:27, Peter Viskup wrote:
before considering downtimes and patching activities on production 
servers

read these:

https://www.debian.org/security/2015/dsa-3142
http://seclists.org/oss-sec/2015/q1/283

especially the second link mention network-facing software which is not
vulnerable due to proper sanitization out of glibc.


Indeed, however you will notice that the list on the second link does 
not contain exim, the default SMTP server software for debian. This was 
used for proof-of-concept code.


http://seclists.org/oss-sec/2015/q1/274

Cheers

Iain



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: 
https://lists.debian.org/d30f1297df8658316e790339af625...@thargoid.co.uk

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:45, andre_deb...@numericable.fr a écrit :

 Je suis sous Wheezy...

Et bien tu mets à jour ta Wheezy de manière on ne peut plus
classique :

apt-get update  apt-get upgrade

Je vois pas où est le problème.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maapf8$ofv$2...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Nicolas KOWALSKI

On Wed, Jan 28, 2015 at 02:43:54PM +0100, Francois Lafont wrote:
 Ah, au fait, petite question. Après les commandes ci-dessus,
 faut-il que je fasse un reboot ?

La commande checkrestart (paquet debian-goodies) permet de savoir 
facilement quels sont les processus à relancer après une mise-à-jour 
classique.

A contrario, une m-a-j de la libc est tellement impactante (tout ou 
presque doit être relancé) que je ne me pose plus la question : c'est 
reboot direct après coup.

-- 
Nicolas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20150128135433.ga2...@petole.demisel.net

Re: glibc bug - time to patch

2015-01-28 Thread Lisi Reisz

On Wednesday 28 January 2015 14:27:18 Lisi Reisz wrote:
 On Wednesday 28 January 2015 13:25:20 i...@thargoid.co.uk wrote:
  On 2015-01-28 12:27, Peter Viskup wrote:
   before considering downtimes and patching activities on production
   servers
   read these:
  


   http://seclists.org/oss-sec/2015/q1/283
  
   especially the second link mention network-facing software which is not
   vulnerable due to proper sanitization out of glibc.
 
  Indeed, however you will notice that the list on the second link does
  not contain exim, the default SMTP server software for debian. This was
  used for proof-of-concept code.
 
  http://seclists.org/oss-sec/2015/q1/274

 So Wheezy users who use Exim are at risk? But it surely then follows that
 Wheezy users who do not use Exim, or even have it installed, are not at
 risk?

   https://www.debian.org/security/2015/dsa-3142

But I see anyway that it has been patched for Wheezy.  So all is OK.

Lisi


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281429.42835.lisi.re...@gmail.com

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread andre_debian

On Wednesday 28 January 2015 13:41:22 Francois Lafont wrote:
 Le 28/01/2015 12:47, Bernard Isambert a écrit :
  Est-ce qu'il y a une chance que le correctif soit tout simplement
  disponible sur les dépôts squeeze « normaux » ?

  Non, seul squeeze-lts évolue encore.

 Ok, merci pour la réponse.

 En même temps ma question était sans doute un peu bête, car le dépôt LTS
 perdrait tout son sens si le dépôt squeeze évoluait encore. ;)

Pourrait-on avoir le mode opératoire sous Debian,
sans faire ce que propose ce site :
www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/#GHOSTVulnerabilityCheck
à savoir # apt-get dist-upgrade
ce qui semble être un peu un canon pour tuer la mouche (même si elle est 
grosse).

N'y a t-il pas une méthode plus soft ?

Merci.

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281419.01720.andre_deb...@numericable.fr

Re: glibc bug - time to patch

2015-01-28 Thread Jochen Spieker

Lisi Reisz:
 On Wednesday 28 January 2015 13:25:20 i...@thargoid.co.uk wrote:
 
 https://www.debian.org/security/2015/dsa-3142
 http://seclists.org/oss-sec/2015/q1/283
 
 especially the second link mention network-facing software which is not
 vulnerable due to proper sanitization out of glibc.
 
 Indeed, however you will notice that the list on the second link does
 not contain exim, the default SMTP server software for debian. This was
 used for proof-of-concept code.
 
 http://seclists.org/oss-sec/2015/q1/274
 
 So Wheezy users who use Exim are at risk?

Yes.

 But it surely then follows that Wheezy users who do not use Exim, or
 even have it installed, are not at risk?

No. The bug is in the most basic C library. I would assume that all
systems with a vulnerable libc are at risk and update as soon as
possible.

J.
-- 
If all my friends had Playstations I would buy a Nintendo to prove my
individuality.
[Agree]   [Disagree]
 http://www.slowlydownward.com/NODATA/data_enter2.html


signature.asc
Description: Digital signature

Re: Faille critique découverte dans GLIBC

Le 28/01/2015 14:34, Francois Lafont a écrit :

 Sous Squeeze ?
 Et bien comme indiqué ici par exemple : https://wiki.debian.org/fr/LTS/Using
 
 Perso, je ne me suis pas embêté :
 
 echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free  
 /etc/apt/sources.list.d/squeeze-lts.list
 apt-get update
 apt-get upgrade

Ah, au fait, petite question. Après les commandes ci-dessus,
faut-il que je fasse un reboot ?

Si j'ai bien compris, si un daemon dépend d'une lib, il faut
redémarrer le-dit daemon après la mise à jour de la-dite lib.
Seulement j'ai cru comprendre que globalement, quasiment tous
les daemons (sous Debian) dépendent in fine de la glibc et
qu'au final un reboot est globalement nécessaire. Bref, j'ai
lu je ne sais plus où que l'idée selon laquelle seule la
màj du noyau nécessitait un reboot était inexacte et que le
reboot était également nécessaire pour la màj de la glic.

Bref, ce serait possible d'avoir un avis d'expert sur la question ? ;)
Merci d'avance.

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maap2l$ofv$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread andre_debian

  Pourrait-on avoir le mode opératoire sous Debian,

 Sous Squeeze ?
 Et bien comme indiqué ici par exemple :
 https://wiki.debian.org/fr/LTS/Using

Je suis sous Wheezy...

 Perso, je ne me suis pas embêté :
 echo deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
  /etc/apt/sources.list.d/squeeze-lts.list apt-get update
 apt-get upgrade
  sans faire ce que propose ce site :
  www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-c
 entos-rhel-linux/#GHOSTVulnerabilityCheck à savoir # apt-get
  dist-upgrade

 Perso, j'avoue que je l'utilise quotidiennement cette commande
 et je n'ai jamais eu de souci. Ai-je tort ?
 Si j'ai bien compris ce que dit la page man, avec upgrade aucune
 chance de voir un paquet supprimé etc. alors qu'avec dist-upgrade
 ça peut arriver.
 Évidemment si je mets des dépôts de la distribution n+1 dans les
 sources.list alors là un dist-upgrade peut faire des dégats mais
 sinon j'ai l'impression que dans 99% des cas un upgrade et un
 dist-upgrade font au final la même chose.
 De toute façon, si tu veux être prudent, tu fais un upgrade et
 puis voilà (en plus même avec un dist-upgrade, tu jettes un œil
 sur les modifications que souhaite faire la commande avant de
 confirmer).
 François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201501281445.58433.andre_deb...@numericable.fr

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Bernard Isambert


Bonjour à tous,

Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 
mais pas en i386.


Le 28/01/2015 08:52, Frédéric MASSOT a écrit :

Quelques autres liens :

- Les paquets corrigés :
https://security-tracker.debian.org/tracker/CVE-2015-0235

- http://www.openwall.com/lists/oss-security/2015/01/27/9
- https://linuxfr.org/users/peetah/journaux/faille-de-securite-glibc
- http://www.frsag.org/pipermail/frsag/2015-January/005722.html



--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8a759.8080...@taranig.net

Re: Faille critique découverte dans GLIBC

Bonjour,

Le 28/01/2015 10:09, Bernard Isambert a écrit :

 Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64 mais 
 pas en i386.

Est-ce qu'il y a une chance que le correctif soit tout simplement disponible
sur les dépôts squeeze « normaux » ?

-- 
François Lafont

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/maafsl$mnj$1...@ger.gmane.org

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Bernard Isambert



Est-ce qu'il y a une chance que le correctif soit tout simplement disponible
sur les dépôts squeeze « normaux » ?


Non, seul squeeze-lts évolue encore.

--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8cc3d.4020...@taranig.net

Re: Faille critique découverte dans GLIBC

2015-01-28 Thread Bernard Isambert




Bonjour à tous,

Pour l'instant, dans les dépôts squeeze-lts, le patch est dispo en amd64
mais pas en i386.



C'était juste une question de temps, maintenant il est arrivé.

--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54c8cd14.6070...@taranig.net

Re: Faille critique découverte dans GLIBC