libX11.so.6 error

2017-09-13 Thread Francesco Pietra
Resent inserting the subjet

While attempting to create a virtual scree with the remote cluster, the
error arose:

/loader/pyi_importers.py", line 409, in load_module
> ImportError: /usr/lib/x86_64-linux-gnu/libX11.so.6: undefined symbol:
> xcb_poll_for_reply64
>

I am at debaian9 amd64. No problem with local graphiocs.

Thasnks for advice

francesco pietra


[no subject]

2017-09-13 Thread Francesco Pietra
While attempting to create a virtual scree with the remote cluster, the
error arose:

/loader/pyi_importers.py", line 409, in load_module
> ImportError: /usr/lib/x86_64-linux-gnu/libX11.so.6: undefined symbol:
> xcb_poll_for_reply64
>

I am at debaian9 amd64. No problem with local graphiocs.

Thasnks for advice

francesco pietra


Re: Updated installer images

2017-09-11 Thread Witold Baryluk
Hi John. Thanks a lot for these images for alpha, I will be trying them
soon probably, as I was unlucky with some previous ones. :)

Thanks.


2017-09-10 21:35 GMT+02:00 Anatoly Pugachev :

> On Sun, Sep 10, 2017 at 10:12 PM, Christoph Biedl
>  wrote:
> > John Paul Adrian Glaubitz wrote...
> >
> >> Please test and report back on the individual architecture
> >> mailing lists
> >
> > So far, the ride for ppc64 has been *extremely* painful. This is not
> > necessarly due to your efforts, but it feels a lot like nobody ever has
> > tried to set up Debian on a G5 using netboot.
> >
> > So far (might be incomplete, and I'm both tired and fairly upset):
> >
> > * Any reasonable documentation on this anywhere? No about how to set up
> >   DHCP/TFTP server, I've done this many time. But what about which files
> >   are needed, and how to provide a netboot-adjusted yaboot.conf, and
> >   mostly: How to make yaboot make using it?
> >
> > * The OF bootloader needs two rounds to load yaboot.
> >
> > * yaboot should either get a decent on-line help or see bitrot.
> >
> > * yaboot's "conf /path/to/config" command, when initially using netboot,
> >   happiliy ignores the file name but retrieves 01-xx-yy-xx-yy-xx-yy
> >   using TFTP instead.
> >
> > * After a lot of trickery, the installer's vmlinux now gets loaded. At a
> >   whopping 6 kbyte/sec (yes: six kilobytes). Just to remind you, kernel
> >   and initrd take some 35 megabytes, and the G5 has already turned to
> >   airplane mode. My neighbors will love me.
> >
> > This isn't getting anywhere useful soon.
>
> I was able to install netboot sparc64 ldom (but not latest sid version
> , which is too big to load by OBP. There's also #645657 debian bug,
> but somehow it got closed).
>
> Also, installed ppc64 LPAR, failed to install yaboot and using grub2
> on Power8 server, but that installation wasn't netboot, but usual
> iso/cdrom install.
>
> I could probably try to install test ppc64 lpar with netboot just to
> check how it will go, but i need to know where do i get netboot image,
> since https://cdimage.debian.org/cdimage/ports/ does not have netboot
> images.
>
> Thanks
>
>


-- 
Witold Baryluk
My PGP keys for 2017-02-17 - 2019-02-17:
5B8C 48CB 8B2F CF53 CA55  0995 16D9 6FA2 20A8 F130
https://functor.xyz/pgp/witold.baryluk-gmail.gpg.asc
https://keys.mailvelope.com/pks/lookup?op=get=0x16D96FA220A8F130


Re: Updated installer images

2017-09-10 Thread Anatoly Pugachev
On Sun, Sep 10, 2017 at 10:12 PM, Christoph Biedl
 wrote:
> John Paul Adrian Glaubitz wrote...
>
>> Please test and report back on the individual architecture
>> mailing lists
>
> So far, the ride for ppc64 has been *extremely* painful. This is not
> necessarly due to your efforts, but it feels a lot like nobody ever has
> tried to set up Debian on a G5 using netboot.
>
> So far (might be incomplete, and I'm both tired and fairly upset):
>
> * Any reasonable documentation on this anywhere? No about how to set up
>   DHCP/TFTP server, I've done this many time. But what about which files
>   are needed, and how to provide a netboot-adjusted yaboot.conf, and
>   mostly: How to make yaboot make using it?
>
> * The OF bootloader needs two rounds to load yaboot.
>
> * yaboot should either get a decent on-line help or see bitrot.
>
> * yaboot's "conf /path/to/config" command, when initially using netboot,
>   happiliy ignores the file name but retrieves 01-xx-yy-xx-yy-xx-yy
>   using TFTP instead.
>
> * After a lot of trickery, the installer's vmlinux now gets loaded. At a
>   whopping 6 kbyte/sec (yes: six kilobytes). Just to remind you, kernel
>   and initrd take some 35 megabytes, and the G5 has already turned to
>   airplane mode. My neighbors will love me.
>
> This isn't getting anywhere useful soon.

I was able to install netboot sparc64 ldom (but not latest sid version
, which is too big to load by OBP. There's also #645657 debian bug,
but somehow it got closed).

Also, installed ppc64 LPAR, failed to install yaboot and using grub2
on Power8 server, but that installation wasn't netboot, but usual
iso/cdrom install.

I could probably try to install test ppc64 lpar with netboot just to
check how it will go, but i need to know where do i get netboot image,
since https://cdimage.debian.org/cdimage/ports/ does not have netboot
images.

Thanks



Re: Updated installer images

2017-09-10 Thread Christoph Biedl
John Paul Adrian Glaubitz wrote...

> Please test and report back on the individual architecture
> mailing lists

So far, the ride for ppc64 has been *extremely* painful. This is not
necessarly due to your efforts, but it feels a lot like nobody ever has
tried to set up Debian on a G5 using netboot.

So far (might be incomplete, and I'm both tired and fairly upset):

* Any reasonable documentation on this anywhere? No about how to set up
  DHCP/TFTP server, I've done this many time. But what about which files
  are needed, and how to provide a netboot-adjusted yaboot.conf, and
  mostly: How to make yaboot make using it?

* The OF bootloader needs two rounds to load yaboot.

* yaboot should either get a decent on-line help or see bitrot.

* yaboot's "conf /path/to/config" command, when initially using netboot,
  happiliy ignores the file name but retrieves 01-xx-yy-xx-yy-xx-yy
  using TFTP instead.

* After a lot of trickery, the installer's vmlinux now gets loaded. At a
  whopping 6 kbyte/sec (yes: six kilobytes). Just to remind you, kernel
  and initrd take some 35 megabytes, and the G5 has already turned to
  airplane mode. My neighbors will love me.

This isn't getting anywhere useful soon.

Christoph


signature.asc
Description: Digital signature


Updated installer images

2017-09-08 Thread John Paul Adrian Glaubitz

Hi!

I have generated an updated set of debian-installer images for
Debian Ports which also now includes alpha [1].

I have fixed the installation issues on hppa and sparc64, in
both cases the bootloader installer was missing.

ppc64 has still some issues with the partition manager, but I'm
working on fixing that.

Please test and report back on the individual architecture
mailing lists, i.e. please don't post to debian-ports@l.d.o
as this reaches the mailing lists of all ports.

Adrian


[1] https://cdimage.debian.org/cdimage/ports/


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



New download location for Debian Ports ISOs

2017-09-06 Thread John Paul Adrian Glaubitz
Hi!

I am cross-posting this to debian-ports@l.d.o because it affects all
Debian Ports architectures.

As of today, we will be using Debian's official cdimage mirror to host
the installation images for Debian Ports, the images can be found in [1].

I have uploaded images for hppa, m68k, ppc64 and sparc64. I am working
on uploading more images. Images for alpha are currently missing due to
issues with the Linux kernel packages which fails to build on alpha at
the moment.

Please test the images as thoroughly as you can and report your results
to the appropriate architecture-specific mailing lists. Please do not
post to this mailing list, debian-ports@l.d.o, as this will cross-post
your mail to ALL Debian Ports architectures mailing lists.

A huge thanks to Steve McIntyre and the Debian Sysadmins for providing
us access to the official cdimage mirror.

Thanks,
Adrian

> [1] https://cdimage.debian.org/cdimage/ports/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#870035: dropbear-bin: ftbfs on x32

2017-07-29 Thread Matthias Fritzsche
Package: dropbear-bin
Version: 2017.75-1
Severity: normal
User: debian-amd64@lists.debian.org
Usertags: x32

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I just saw that there is only an very old version of dropbear in the
repository and tried to build current 2017.75. This fails in the file
tomcrypt_macros.h with an error similar to
https://wiki.debian.org/X32Port#amd64_assembly.

Attached is a full build log.

kind regards
txt.file

-BEGIN PGP SIGNATURE-

iQJIBAEBCAAyFiEE1NOunmXPptEkFyWqOb+C9VkIZegFAll8LcUUHHR4dC5maWxl
QHR4dGZpbGUuZXUACgkQOb+C9VkIZehnIBAAkMy+0k+NrJhNyf5ep1bxD/54L+et
FVGGg1f80UophMfnC83EH8UjapvJ1aNtmizpt4dcFMcnaneMFzPd6FZZZwUueNJ4
4F5yQJfIh4SnJBWWlOvjGH9WNMTXkWx6RnwZFV+Z1ITSCorgf70bjM7GNKg2WR5D
8yQ2sU5VVp50/Li2RWR2pOewbupyWaor0XV6q1YLb60qFoGcHiZoe/b9qh5zs/ZP
2mkb5sh2oUnDi2WhbwLnEYZReMwoFSdtJm8OIO2zCS5oskcNqEICB53b6seIuKe5
Th+cLM/MOaFWsr36qlLnjF546ocBiu54Vk48Hc7Cba+pH7YzxPNm+cz27nhIVh6M
VlkpuInLwDXgCtMtnAy7QgLPMzitfoGhMqfN52srdPFDIevEcVyzsO7zvyD/vTqA
0E353uNX83LxuDVEbwEYUwZjSk/x3agqvvJUDNnJbIGeZ61vJmNrVSH1m4wWVUzb
AJr8ZFdUd/fYH1CMklhcND5xO2KDDOmMa/vf0MxnYx/0txJ0wfvQNa2G6qQsFIuS
8x3CDsIp6f3cSfEXdk7cOZHQ0e8kuQD4JTNQ5wvOy7FF9AW2pCE83AoJMik9jsIt
0BgoUKtyc36aG103z1Nw9ke9yczuTD48ntSDHRIwcfk6RuQmGqEPrHfz67+lGJoI
hNMxP9sTE8QjRSM=
=SRln
-END PGP SIGNATURE-
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package dropbear
dpkg-buildpackage: info: source version 2017.75-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Guilhem Moulin 
 dpkg-source --before-build dropbear-2017.75
dpkg-buildpackage: info: host architecture x32
 fakeroot debian/rules clean
dh clean --with=autoreconf
   dh_testdir
   dh_auto_clean
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b dropbear-2017.75
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building dropbear using existing 
./dropbear_2017.75.orig.tar.bz2
dpkg-source: info: building dropbear in dropbear_2017.75-1.debian.tar.xz
dpkg-source: info: building dropbear in dropbear_2017.75-1.dsc
 debian/rules build
dh build --with=autoreconf
   dh_testdir
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/txt/workspace/dropbear-2017.75'
dh_auto_configure -- --enable-bundled-libtom \
  CC='gcc' CFLAGS='-g -O2 
-fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -DSFTPSERVER_PATH="\"/usr/lib/sftp-server\""' \
  
./configure --build=x86_64-linux-gnux32 --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnux32 
--libexecdir=\${prefix}/lib/x86_64-linux-gnux32 --disable-maintainer-mode 
--disable-dependency-tracking --enable-bundled-libtom CC=gcc "CFLAGS=-g -O2 
-fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -DSFTPSERVER_PATH=\"\\\"/usr/lib/sftp-server\\\"\""
configure: WARNING: unrecognized options: --disable-silent-rules, 
--disable-maintainer-mode, --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether make sets $(MAKE)... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking build system type... x86_64-pc-linux-gnux32
checking host system type... x86_64-pc-linux-gnux32
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for install... install
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __UCLIBC__ is declared... no
checking for crypt... no
checking for crypt in -lcrypt... yes
checking for deflate in -lz... yes
configure: Enabling zlib
configure: Disabling PAM
configure: Using openpty if available
checking for library containing openpty... -lutil
configure: Enabling syslog
checking shadow.h usability... yes
checking shadow.h presence... 

Re: dropbear: tfbfs on x32

2017-07-29 Thread John Paul Adrian Glaubitz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Matthias!

On 07/29/2017 07:55 AM, txt.file wrote:
> I just saw that there is only an very old version of dropbear in the 
> repository and tried to build current 2017.75. This fails in the file 
> tomcrypt_macros.h with an error similar to 
> https://wiki.debian.org/X32Port#amd64_assembly.

Please refrain from posting such issues to debian-po...@lists.debian.org
as this is a list which cross-posts to all ports mailing lists.

Instead, just file a bug report against dropbear and tag it as "x32"

User: debian-amd64@lists.debian.org
Usertags: x32
X-Debbugs-CC: debian-amd64@lists.debian.org

If you want to reach Debian Ports, please use debian-ports-devel@l.d.o
instead.

Thanks,
Adrian

- -- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYv+KdYTgKVaVRgAGdCY7N/W1+RMFAll8KMQACgkQdCY7N/W1
+RPDdg//cXTyzqTgV6Q92bliaNLpnHFQUSfByNxVuMnJUU9cSfQ6DSNDZbmE0Sz3
P1Vdy3ozfkWMDJmP4uBhclG2mEVRFwRA7aRVBBVP/+ibdsTYFTU31yWVVvdrHpkk
k5W5qU8RVK8epAw1g6WGF7oxz1aixXIQF8yHamK9HI6Ywi3lbFB0J+kHHdxWXmt7
gRtWd0YCzcYESRg7bMC6fP3q8fEMeU8sSxQ6MDkfY6NpYw4DmE7vjUzV4vpVgapi
bF1IFqN7xWoLPCy5IiPjKYbKyAISHpFEPMPi1DAPXuClXLsfZtK3jJDRw9iddj6Y
adnG+NuAcoNM+HYRfrezKkZuLGBm1NJqXjcyTf17cIrQIGIZvTi4R+Lop85U7ymi
9dIHu3xF0zG5FbviKdpzjBIHMndblS5cGzuyRy+NJL1pUVyfzOf/KgVqVlcCOM9p
4f2vT+pT5+X3ZzocxQ/Kf6ySqGKnqznXhj+lGOs1Ix/dNpuyp1UyQouyAYjxCXdi
GTuDDrODb+F1iJKkMYdO76FgbPVLby8vRDrGW33iwKMUHslPAxR7GM88A2DbbM9s
v7BG+jQkTleIvoNNrWLWrYCX/ZYTQHHlFX6qppstge1pAzukZO74E+oJPKvGNrre
tuFFkFKU6yarOilJP7uB9kHR0MaDzFhAVSpWJPZF79pm2AhwcF4=
=rX5e
-END PGP SIGNATURE-



dropbear: tfbfs on x32

2017-07-28 Thread txt.file
I just saw that there is only an very old version of dropbear in the
repository and tried to build current 2017.75. This fails in the file
tomcrypt_macros.h with an error similar to
https://wiki.debian.org/X32Port#amd64_assembly.

Attached is a full build log.

kind regards
txt.file
 dpkg-buildpackage -rfakeroot -us -uc
dpkg-buildpackage: info: source package dropbear
dpkg-buildpackage: info: source version 2017.75-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Guilhem Moulin 
 dpkg-source --before-build dropbear-2017.75
dpkg-buildpackage: info: host architecture x32
 fakeroot debian/rules clean
dh clean --with=autoreconf
   dh_testdir
   dh_auto_clean
   dh_autoreconf_clean
   dh_clean
 dpkg-source -b dropbear-2017.75
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building dropbear using existing ./dropbear_2017.75.orig.tar.bz2
dpkg-source: info: building dropbear in dropbear_2017.75-1.debian.tar.xz
dpkg-source: info: building dropbear in dropbear_2017.75-1.dsc
 debian/rules build
dh build --with=autoreconf
   dh_testdir
   dh_update_autotools_config
   dh_autoreconf
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/home/txt/workspace/dropbear-2017.75'
dh_auto_configure -- --enable-bundled-libtom \
  CC='gcc' CFLAGS='-g -O2 -fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DSFTPSERVER_PATH="\"/usr/lib/sftp-server\""' \
  
	./configure --build=x86_64-linux-gnux32 --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnux32 --libexecdir=\${prefix}/lib/x86_64-linux-gnux32 --disable-maintainer-mode --disable-dependency-tracking --enable-bundled-libtom CC=gcc "CFLAGS=-g -O2 -fdebug-prefix-map=/home/txt/workspace/dropbear-2017.75=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -DSFTPSERVER_PATH=\"\\\"/usr/lib/sftp-server\\\"\""
configure: WARNING: unrecognized options: --disable-silent-rules, --disable-maintainer-mode, --disable-dependency-tracking
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether make sets $(MAKE)... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking build system type... x86_64-pc-linux-gnux32
checking host system type... x86_64-pc-linux-gnux32
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking for install... install
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether __UCLIBC__ is declared... no
checking for crypt... no
checking for crypt in -lcrypt... yes
checking for deflate in -lz... yes
configure: Enabling zlib
configure: Disabling PAM
configure: Using openpty if available
checking for library containing openpty... -lutil
configure: Enabling syslog
checking shadow.h usability... yes
checking shadow.h presence... yes
checking for shadow.h... yes
configure: Using shadow passwords if available
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking netinet/tcp.h usability... yes
checking netinet/tcp.h presence... yes
checking for netinet/tcp.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for unistd.h... (cached) yes
checking crypt.h usability... 

Re: updating mysql failed.. debian 9

2017-07-23 Thread Adrian Bunk
On Tue, Jul 18, 2017 at 03:32:07AM -0700, DutchGigalo wrote:
> updating mysql failed.. debian 9 
> 
> Preparing to unpack .../mysql-community-server_5.7.19-1debian9_amd64.deb ...
> 
> dpkg: error processing archive
> /var/cache/apt/archives/mysql-community-server_5.7.19-1debian9_amd64.deb
> (--unpack):
>  subprocess new pre-installation script returned error exit status 1
> Errors were encountered while processing:
>  /var/cache/apt/archives/mysql-community-server_5.7.19-1debian9_amd64.deb

This Community Server server package is from Oracle, not from Debian.

Please report this problem to Oracle/MySQL.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



updating mysql failed.. debian 9

2017-07-18 Thread DutchGigalo
updating mysql failed.. debian 9 

Preparing to unpack .../mysql-community-server_5.7.19-1debian9_amd64.deb ...

dpkg: error processing archive
/var/cache/apt/archives/mysql-community-server_5.7.19-1debian9_amd64.deb
(--unpack):
 subprocess new pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/mysql-community-server_5.7.19-1debian9_amd64.deb





--
View this message in context: 
http://debian.2.n7.nabble.com/updating-mysql-failed-debian-9-tp4152313.html
Sent from the debian-amd64 mailing list archive at Nabble.com.



Re: Actualizar esta de moda

2017-07-10 Thread Auto Admi
Hola,Hace 16 años que presto asesorías en el área del diseño de sitios web 
a pequeños y medianos empresarios.No soy un diseñador
cualquiera, con el tiempo he logrado diferenciarme del resto. Aquí algunas 
razones:

Soy fanático de la puntualidad.
Si no te gusta no lo pagas.
Primero diseño, después cobro.
Puedes conversar conmigo y siempre haré lo humanamente posible para comprender 
tus ideas y ponerlas en tu diseño.
He construido una red de valor con mis clientes y ellos son mi mejor y mayor 
punto de referencia a la hora de pedirme credenciales de lo anteriormente
dicho.

Mi desafío hoy es ayudarte a contar con un muy buen sitio web, en el que no 
solo te veas reflejado junto a la empresa que te enorgullece, sino que
también te permita atender bien a tus clientes, sacarlos de sus dudas y 
objeciones y darles el empujoncito final para convertirse en compradores de
calidad.
 Maquetea conmigo 
Desarrollemos un demo de tu nuevo sitio web, con tus productos y servicios.  A 
ver si te gusta y te calsan los precios, como a ellos:   
www.ecoplantas.cl  www.fervore.cl  www.foodacomer.cl  www.mundoauto.cl  
www.pierattini.cl  www.procesadorasanfrancisco.clPor eso te invito a   
Maquetear tus ideas ( 
http://sub.lanzamientoschile.com/index.php?subid=47189=com_acymailing=url=3=39
 )
 Si, a ponerlas en línea. 
 Mi compromiso es que, si no te gusta, sigo siendo tan amigo tuyo como cuando 
me pediste que hiciera realidad lo que tienes en mente. Claro, lo que
quiero es que cuando termine de hacer la demo, te guste tanto que me la 
compres, eso no tiene nada de malo, si de esto vivo.Te saluda muy
afectuosamente.Sergio López Neira
Diseñador web  Dueño de éste sueño que se llama Autoadministrable.cl 
 
Pideme tu maqueta aquí 
www.autoadministrable.cl ( 
http://sub.lanzamientoschile.com/index.php?subid=47189=com_acymailing=url=2=39
 ) | Contacto
http://www.autoadministrable.cl/ventas/test/28-jinbound-landing-pages/1-formulario-test.html
 
 
Borrarme de lista ( 
http://sub.lanzamientoschile.com/index.php?subid=47189=com_acymailing=user=out=39=ghNPMJkJ8qZc3I
 )
 {tag:subscriptions} 

 {tag:unsubscribe}



BAG in DEBIAN 8.8

2017-06-16 Thread МБУЗ ГКБ № 1



 Пересылаемое сообщение 
От кого: МБУЗ ГКБ № 1 
Кому: debian-de...@lists.debian.org
Дата: Пятница, 16 июня 2017, 19:05 +03:00
Тема: Help me

Hi no work in Debian 8.8
No start firebird 2.5 classic and super 
error
work@work-desktop ~ $ sudo dpkg-reconfigure firebird2.5-classic
[sudo] password for work: 
GSEC> GSEC> update-rc.d: warning: start and stop actions are no longer 
supported; falling back to defaults
no stat process




--





Re: mpich FTBFS on sh4: MPIUI_Thread TLS definition mismatches tbss

2017-06-06 Thread Aaron M. Ucko
Drew Parsons  writes:

> The link error suggests 2 different versions of MPIUI_Thread are used. 
> But I can only see a definition in src/util/thread/mpiu_thread.c.
> src/mpi/comm does not refer to it, and comm_rank.c does not use any
> MPIU object. So the error message doesn't make sense to me.

comm_rank's reference to MPIUI_Thread is also present on at least amd64,
and presumably due to some macro that (directly or indirectly) calls
MPIU_THREADPRIV_FIELD.  However, it's not clear why multithreaded build
settings would be in effect for mpiu_thread but not also comm_rank.  (It
looks like MPIUI_Thread's thread-locality is conditional on
MPICH_IS_THREADED, which mpichconf.h defines centrally.)

I don't have time to dig deeper, but hope that brief analysis helps.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu



about nvidia-toolkit

2017-06-06 Thread Francesco Pietra
Hi:
My question is whether the nvidia-toolkit could be removed from the
installation of stretch amd64. I use GTX 680  for only number crunching,
not development.

If so, there is any special protocol for removing the nvidia-toolkit
withouth harming the GTX680 functionality as above said.

The reason is that updating/upgrading of the nvidia-toolkit takes so long.

Thanks

francesco pietra


Lonely housewifes hook up

2017-06-03 Thread Mark Middleton
I need the hookup


Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-22 Thread Francesco Pietra
NEW:I have finally obtained a red-labeled line on booting, telling "Failed
to load console system Reboot Logging"

This implies that it is not merely a problem of console ownership.

A rapid web survey failed to provide indications as to having the console
loaded during booting on Debian amd64 stretch.

hope someone knows that

On Sun, May 21, 2017 at 7:22 PM, Francesco Pietra 
wrote:

> I should add that, once the Xserver is launched by the aid of the other
> computer on LAN, the server works autonomously from its keyboard and
> terminals. I could run at an impressively high speed a most recent special
> form of molecular dynamics on the six cores, six threads, and the two
> GTX680 combined, with a recent cuda driver (375.39, offered by stretch).
> This is a very strict test. I could use the server this way for my
> scientific work but it would be unaesthetic at the best.
>
> The need of setting the Xwrapper to anybody confirms that the user has no
> command of the console, but I was unable to go on this way toward avoiding
> the external assistance.
>
> fp
>
> On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra 
> wrote:
>
>> Back to your suspicion about the GTX680, I was really surprised that the
>> Xserver could be raised from the other computer (vaio) on the LAN, only as
>> a superuser.
>>
>> I had to change "allowed_users=console" (which is default on all my linux
>> boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config.
>>
>> This way the "X" or "startx" commands do their job perfectly, however
>> only from the vaio console. In the "defective" system, rebooting from the
>> console brings again to warnings about failure to connect to lvmetad and
>> EDAC sbridge, followed the login prompt, which disappears immediately, and
>> then "disk scanning" and no way to get the login prompt prompt via
>> Ctrl+AlT+F2 (or F1 or F3). Like for a dead console.
>>
>> At this point, all that appears to be a silly problem but I could not
>> find a solution. Having to  reinstall amd64 would be a defeat.
>>
>> fp
>>
>>
>> On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra 
>> wrote:
>>
>>> Your server is booting, but not providing a login

>>>
>>> I forgot to say that the request of username/password does indeed appear
>>> during booting but transiently, followed by that interminable access to
>>> disk. I was unable to stop (with Ctrl-S) at the login request.
>>>
>>> Can you log in on
 a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?

>>>
>>> No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.
>>>
>>> from the VAIO, what does "grep -E 'WW|EE'
 /var/log/Xorg.0.log" show (on the server, perhaps as root)?

>>>
>>> francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does
>>> not exist.
>>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd',
>>> 'mouse' or 'vmmouse' will be disabled.
>>> [56.070] (WW) Disabling Keyboard0
>>> [56.070] (WW) Disabling Mouse0
>>> francesco@.:~$ su
>>> Password:
>>> root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
>>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does
>>> not exist.
>>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd',
>>> 'mouse' or 'vmmouse' will be disabled.
>>> [56.070] (WW) Disabling Keyboard0
>>> [56.070] (WW) Disabling Mouse0
>>> root@...:/home/francesco#
>>>
>>> Those two GPUs had worked without problems on this server with wheezy,
>>> and after that on upgrading to jessie.
>>>
>>> thanks a lot for your kind help
>>>
>>> francesco pietra
>>>
>>>
>>>
>>> On Fri, May 19, 2017 at 11:32 AM, Darac Marjal >> > wrote:
>>>
 On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote:

> "It is not required for normal usage"
>
>   The fact is that the X79-based computer does not offer a login
>   possibility, it goes to disk scanning (kernel et al) for hours (at
>   least 4hr).
>
>   Access to file was only possible from a LAN-connected other computer
>   (laptop VAIO) or booting from Super Grub2 disk.
>
>   Whether all issues arise from inability to connect to lvmetad, I
>   cannot say. I am no system analyzer. I merely need the X79-GPU-based
>   machine for applications (molecular dynamics with recent CUDA).
>   fp
>

 Personally, I doubt that your GPU (Graphics Processing Unit) is related
 to how the disks are access, but perhaps you've got a very special
 system.

 Also, I'm not sure what issue you're... Oh, I see what's happening!

 Your server is booting, but not providing a login. You ARE able to log
 into the server 

Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-21 Thread Francesco Pietra
I should add that, once the Xserver is launched by the aid of the other
computer on LAN, the server works autonomously from its keyboard and
terminals. I could run at an impressively high speed a most recent special
form of molecular dynamics on the six cores, six threads, and the two
GTX680 combined, with a recent cuda driver (375.39, offered by stretch).
This is a very strict test. I could use the server this way for my
scientific work but it would be unaesthetic at the best.

The need of setting the Xwrapper to anybody confirms that the user has no
command of the console, but I was unable to go on this way toward avoiding
the external assistance.

fp

On Sun, May 21, 2017 at 11:32 AM, Francesco Pietra 
wrote:

> Back to your suspicion about the GTX680, I was really surprised that the
> Xserver could be raised from the other computer (vaio) on the LAN, only as
> a superuser.
>
> I had to change "allowed_users=console" (which is default on all my linux
> boxes) to "allowed_users=anybody" in /etc/X11/Xwrapper.config.
>
> This way the "X" or "startx" commands do their job perfectly, however only
> from the vaio console. In the "defective" system, rebooting from the
> console brings again to warnings about failure to connect to lvmetad and
> EDAC sbridge, followed the login prompt, which disappears immediately, and
> then "disk scanning" and no way to get the login prompt prompt via
> Ctrl+AlT+F2 (or F1 or F3). Like for a dead console.
>
> At this point, all that appears to be a silly problem but I could not find
> a solution. Having to  reinstall amd64 would be a defeat.
>
> fp
>
>
> On Fri, May 19, 2017 at 4:12 PM, Francesco Pietra 
> wrote:
>
>> Your server is booting, but not providing a login
>>>
>>
>> I forgot to say that the request of username/password does indeed appear
>> during booting but transiently, followed by that interminable access to
>> disk. I was unable to stop (with Ctrl-S) at the login request.
>>
>> Can you log in on
>>> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?
>>>
>>
>> No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.
>>
>> from the VAIO, what does "grep -E 'WW|EE'
>>> /var/log/Xorg.0.log" show (on the server, perhaps as root)?
>>>
>>
>> francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
>> exist.
>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse'
>> or 'vmmouse' will be disabled.
>> [56.070] (WW) Disabling Keyboard0
>> [56.070] (WW) Disabling Mouse0
>> francesco@.:~$ su
>> Password:
>> root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
>> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
>> exist.
>> [56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse'
>> or 'vmmouse' will be disabled.
>> [56.070] (WW) Disabling Keyboard0
>> [56.070] (WW) Disabling Mouse0
>> root@...:/home/francesco#
>>
>> Those two GPUs had worked without problems on this server with wheezy,
>> and after that on upgrading to jessie.
>>
>> thanks a lot for your kind help
>>
>> francesco pietra
>>
>>
>>
>> On Fri, May 19, 2017 at 11:32 AM, Darac Marjal 
>> wrote:
>>
>>> On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote:
>>>
 "It is not required for normal usage"

   The fact is that the X79-based computer does not offer a login
   possibility, it goes to disk scanning (kernel et al) for hours (at
   least 4hr).

   Access to file was only possible from a LAN-connected other computer
   (laptop VAIO) or booting from Super Grub2 disk.

   Whether all issues arise from inability to connect to lvmetad, I
   cannot say. I am no system analyzer. I merely need the X79-GPU-based
   machine for applications (molecular dynamics with recent CUDA).
   fp

>>>
>>> Personally, I doubt that your GPU (Graphics Processing Unit) is related
>>> to how the disks are access, but perhaps you've got a very special
>>> system.
>>>
>>> Also, I'm not sure what issue you're... Oh, I see what's happening!
>>>
>>> Your server is booting, but not providing a login. You ARE able to log
>>> into the server using another computer on the network. This means that
>>> the server HAS booted from the disk(s). LVM is *not* your problem (if it
>>> was, the system would probably not be able to load
>>> /etc/network/interfaces in order to bring up the network, nor the SSH
>>> daemon, nor the user's home directory ...)
>>>
>>> The issue you're having is more likely with that GPU. Can you log in on
>>> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When
>>> you log in from the VAIO, what does "grep -E 'WW|EE'
>>> 

Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Francesco Pietra
>
> Your server is booting, but not providing a login
>

I forgot to say that the request of username/password does indeed appear
during booting but transiently, followed by that interminable access to
disk. I was unable to stop (with Ctrl-S) at the login request.

Can you log in on
> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)?
>

No, nothing happens with on Ctrl+Alt+F2 from the GPU server keyboard.

from the VAIO, what does "grep -E 'WW|EE'
> /var/log/Xorg.0.log" show (on the server, perhaps as root)?
>

francesco@.:~$ grep -E 'WW|EE' /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse'
or 'vmmouse' will be disabled.
[56.070] (WW) Disabling Keyboard0
[56.070] (WW) Disabling Mouse0
francesco@.:~$ su
Password:
root@.:/home/francesco# grep -E 'WW|EE' /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[56.025] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[56.070] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse'
or 'vmmouse' will be disabled.
[56.070] (WW) Disabling Keyboard0
[56.070] (WW) Disabling Mouse0
root@...:/home/francesco#

Those two GPUs had worked without problems on this server with wheezy, and
after that on upgrading to jessie.

thanks a lot for your kind help

francesco pietra



On Fri, May 19, 2017 at 11:32 AM, Darac Marjal 
wrote:

> On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote:
>
>> "It is not required for normal usage"
>>
>>   The fact is that the X79-based computer does not offer a login
>>   possibility, it goes to disk scanning (kernel et al) for hours (at
>>   least 4hr).
>>
>>   Access to file was only possible from a LAN-connected other computer
>>   (laptop VAIO) or booting from Super Grub2 disk.
>>
>>   Whether all issues arise from inability to connect to lvmetad, I
>>   cannot say. I am no system analyzer. I merely need the X79-GPU-based
>>   machine for applications (molecular dynamics with recent CUDA).
>>   fp
>>
>
> Personally, I doubt that your GPU (Graphics Processing Unit) is related
> to how the disks are access, but perhaps you've got a very special
> system.
>
> Also, I'm not sure what issue you're... Oh, I see what's happening!
>
> Your server is booting, but not providing a login. You ARE able to log
> into the server using another computer on the network. This means that
> the server HAS booted from the disk(s). LVM is *not* your problem (if it
> was, the system would probably not be able to load
> /etc/network/interfaces in order to bring up the network, nor the SSH
> daemon, nor the user's home directory ...)
>
> The issue you're having is more likely with that GPU. Can you log in on
> a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When
> you log in from the VAIO, what does "grep -E 'WW|EE'
> /var/log/Xorg.0.log" show (on the server, perhaps as root)?
>
>   On Fri, May 19, 2017 at 10:24 AM, Darac Marjal
>>   <[1]mailingl...@darac.org.uk> wrote:
>>
>> On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote:
>>
>> Hello:
>> On a vintage VAIO I have no problems with amd64 stretch. With a
>> raid1-based on the X79 chip, upgrading from jessie to stretch
>>   (I need
>> a higher CUDA version than available on jessie for latest
>> experimental NAMD molecular dynamics) went on regularly.
>>   However, the
>> command
>>
>> # systemctl set-default multi-user.target
>>
>> (which worked fine on said VAIO to boot at the $ linux prompt)
>>   led to
>> failure to connect to lvmetad, falling back to device scanning,
>> whereby an endless disk scanning begun.
>>
>> I tried:
>>
>> 1) Super grub2 disk: OK it led to clean boot but I found no way
>>   to
>> fix the problem.
>>
>> 2) Accessing the X79 computer from said VAIO (both are on a
>>   LAN)
>> equally allowed to manage everything but I was unable to fix
>>   the
>> problem.
>>
>> 3) From said VAIO:
>>  # systemctl enable lvm2-lvmetad.service
>>
>> OK, but it was lost on needed reboot.
>>
>> I never had to reinstall a debian amd64 but this time I am
>>   lost.
>>
>> Thanks for any kind suggestion
>>
>> Have you enabled the daemon in lvm.conf? Look for "use_lvmetad".
>>
>> However, I think this should not be a problem. lvmetad is the LVM
>> Metadata Daemon, which is primarily a caching daemon. If you have a
>> lot
>> of disks, or change your logical volumes frequently, the lvmetad
>> can
>> speed up the varioud LVM commands. It is not required for normal
>> usage
>> and ~99% of people can ignore the "failure 

Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Darac Marjal

On Fri, May 19, 2017 at 11:12:25AM +0200, Francesco Pietra wrote:

"It is not required for normal usage"

  The fact is that the X79-based computer does not offer a login
  possibility, it goes to disk scanning (kernel et al) for hours (at
  least 4hr).

  Access to file was only possible from a LAN-connected other computer
  (laptop VAIO) or booting from Super Grub2 disk.

  Whether all issues arise from inability to connect to lvmetad, I
  cannot say. I am no system analyzer. I merely need the X79-GPU-based
  machine for applications (molecular dynamics with recent CUDA).
  fp


Personally, I doubt that your GPU (Graphics Processing Unit) is related
to how the disks are access, but perhaps you've got a very special
system.

Also, I'm not sure what issue you're... Oh, I see what's happening!

Your server is booting, but not providing a login. You ARE able to log
into the server using another computer on the network. This means that
the server HAS booted from the disk(s). LVM is *not* your problem (if it
was, the system would probably not be able to load
/etc/network/interfaces in order to bring up the network, nor the SSH
daemon, nor the user's home directory ...)

The issue you're having is more likely with that GPU. Can you log in on
a VT console (press Ctrl+Alt+F2 to see if you get a login prompt)? When
you log in from the VAIO, what does "grep -E 'WW|EE'
/var/log/Xorg.0.log" show (on the server, perhaps as root)?


  On Fri, May 19, 2017 at 10:24 AM, Darac Marjal
  <[1]mailingl...@darac.org.uk> wrote:

On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote:

    Hello:
    On a vintage VAIO I have no problems with amd64 stretch. With a
    raid1-based on the X79 chip, upgrading from jessie to stretch
  (I need
    a higher CUDA version than available on jessie for latest
    experimental NAMD molecular dynamics) went on regularly.
  However, the
    command

    # systemctl set-default multi-user.target

    (which worked fine on said VAIO to boot at the $ linux prompt)
  led to
    failure to connect to lvmetad, falling back to device scanning,
    whereby an endless disk scanning begun.

    I tried:

    1) Super grub2 disk: OK it led to clean boot but I found no way
  to
    fix the problem.

    2) Accessing the X79 computer from said VAIO (both are on a
  LAN)
    equally allowed to manage everything but I was unable to fix
  the
    problem.

    3) From said VAIO:
     # systemctl enable lvm2-lvmetad.service

    OK, but it was lost on needed reboot.

    I never had to reinstall a debian amd64 but this time I am
  lost.

    Thanks for any kind suggestion

Have you enabled the daemon in lvm.conf? Look for "use_lvmetad".

However, I think this should not be a problem. lvmetad is the LVM
Metadata Daemon, which is primarily a caching daemon. If you have a
lot
of disks, or change your logical volumes frequently, the lvmetad
can
speed up the varioud LVM commands. It is not required for normal
usage
and ~99% of people can ignore the "failure to connect" message.

    francesco pietra
     

--
For more information, please reread.

References

  Visible links
  1. mailto:mailingl...@darac.org.uk


--
For more information, please reread.


signature.asc
Description: PGP signature


Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Francesco Pietra
>
> "It is not required for normal usage"
>

The fact is that the X79-based computer does not offer a login possibility,
it goes to disk scanning (kernel et al) for hours (at least 4hr).

Access to file was only possible from a LAN-connected other computer
(laptop VAIO) or booting from Super Grub2 disk.

Whether all issues arise from inability to connect to lvmetad, I cannot
say. I am no system analyzer. I merely need the X79-GPU-based machine for
applications (molecular dynamics with recent CUDA).

fp

On Fri, May 19, 2017 at 10:24 AM, Darac Marjal 
wrote:

> On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote:
>
>>   Hello:
>>   On a vintage VAIO I have no problems with amd64 stretch. With a
>>   raid1-based on the X79 chip, upgrading from jessie to stretch (I need
>>   a higher CUDA version than available on jessie for latest
>>   experimental NAMD molecular dynamics) went on regularly. However, the
>>   command
>>
>>   # systemctl set-default multi-user.target
>>
>>   (which worked fine on said VAIO to boot at the $ linux prompt) led to
>>   failure to connect to lvmetad, falling back to device scanning,
>>   whereby an endless disk scanning begun.
>>
>>   I tried:
>>
>>   1) Super grub2 disk: OK it led to clean boot but I found no way to
>>   fix the problem.
>>
>>   2) Accessing the X79 computer from said VAIO (both are on a LAN)
>>   equally allowed to manage everything but I was unable to fix the
>>   problem.
>>
>>   3) From said VAIO:
>># systemctl enable lvm2-lvmetad.service
>>
>>   OK, but it was lost on needed reboot.
>>
>>   I never had to reinstall a debian amd64 but this time I am lost.
>>
>>   Thanks for any kind suggestion
>>
>
> Have you enabled the daemon in lvm.conf? Look for "use_lvmetad".
>
> However, I think this should not be a problem. lvmetad is the LVM
> Metadata Daemon, which is primarily a caching daemon. If you have a lot
> of disks, or change your logical volumes frequently, the lvmetad can
> speed up the varioud LVM commands. It is not required for normal usage
> and ~99% of people can ignore the "failure to connect" message.
>
>
>>   francesco pietra
>>
>>
>
> --
> For more information, please reread.
>


Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Francesco Pietra
I forgot to mention that

---changing in /etc/lvm from "use_lvmetad=1" to "use_lvmetad=0"

or commenting out in /etc/defaut/grub

---# GRUB_CMDLINE_LINUX_DEFAULT="quiet"

did not solve the problem


fp

On Fri, May 19, 2017 at 10:21 AM, Francesco Pietra 
wrote:

> I understand that udev is in focus, however I don't know how to marriage
> lvmetad and udev
>
> francesco pietra
>
> On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra 
> wrote:
>
>> Hello:
>> On a vintage VAIO I have no problems with amd64 stretch. With a
>> raid1-based on the X79 chip, upgrading from jessie to stretch (I need a
>> higher CUDA version than available on jessie for latest experimental NAMD
>> molecular dynamics) went on regularly. However, the command
>>
>> # systemctl set-default multi-user.target
>>
>> (which worked fine on said VAIO to boot at the $ linux prompt) led to
>> failure to connect to lvmetad, falling back to device scanning, whereby an
>> endless disk scanning begun.
>>
>> I tried:
>>
>> 1) Super grub2 disk: OK it led to clean boot but I found no way to fix
>> the problem.
>>
>> 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally
>> allowed to manage everything but I was unable to fix the problem.
>>
>> 3) From said VAIO:
>>  # systemctl enable lvm2-lvmetad.service
>>
>> OK, but it was lost on needed reboot.
>>
>> I never had to reinstall a debian amd64 but this time I am lost.
>>
>> Thanks for any kind suggestion
>>
>> francesco pietra
>>
>>
>>
>>
>>
>


Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Darac Marjal

On Fri, May 19, 2017 at 10:17:44AM +0200, Francesco Pietra wrote:

  Hello:
  On a vintage VAIO I have no problems with amd64 stretch. With a
  raid1-based on the X79 chip, upgrading from jessie to stretch (I need
  a higher CUDA version than available on jessie for latest
  experimental NAMD molecular dynamics) went on regularly. However, the
  command

  # systemctl set-default multi-user.target

  (which worked fine on said VAIO to boot at the $ linux prompt) led to
  failure to connect to lvmetad, falling back to device scanning,
  whereby an endless disk scanning begun.

  I tried:

  1) Super grub2 disk: OK it led to clean boot but I found no way to
  fix the problem.

  2) Accessing the X79 computer from said VAIO (both are on a LAN)
  equally allowed to manage everything but I was unable to fix the
  problem.

  3) From said VAIO:
   # systemctl enable lvm2-lvmetad.service

  OK, but it was lost on needed reboot.

  I never had to reinstall a debian amd64 but this time I am lost.

  Thanks for any kind suggestion


Have you enabled the daemon in lvm.conf? Look for "use_lvmetad".

However, I think this should not be a problem. lvmetad is the LVM
Metadata Daemon, which is primarily a caching daemon. If you have a lot
of disks, or change your logical volumes frequently, the lvmetad can
speed up the varioud LVM commands. It is not required for normal usage
and ~99% of people can ignore the "failure to connect" message.



  francesco pietra
   


--
For more information, please reread.


signature.asc
Description: PGP signature


Re: debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Francesco Pietra
I understand that udev is in focus, however I don't know how to marriage
lvmetad and udev

francesco pietra

On Fri, May 19, 2017 at 10:17 AM, Francesco Pietra 
wrote:

> Hello:
> On a vintage VAIO I have no problems with amd64 stretch. With a
> raid1-based on the X79 chip, upgrading from jessie to stretch (I need a
> higher CUDA version than available on jessie for latest experimental NAMD
> molecular dynamics) went on regularly. However, the command
>
> # systemctl set-default multi-user.target
>
> (which worked fine on said VAIO to boot at the $ linux prompt) led to
> failure to connect to lvmetad, falling back to device scanning, whereby an
> endless disk scanning begun.
>
> I tried:
>
> 1) Super grub2 disk: OK it led to clean boot but I found no way to fix the
> problem.
>
> 2) Accessing the X79 computer from said VAIO (both are on a LAN) equally
> allowed to manage everything but I was unable to fix the problem.
>
> 3) From said VAIO:
>  # systemctl enable lvm2-lvmetad.service
>
> OK, but it was lost on needed reboot.
>
> I never had to reinstall a debian amd64 but this time I am lost.
>
> Thanks for any kind suggestion
>
> francesco pietra
>
>
>
>
>


debian9 amd64 failure to connect to lvmetad, falling back to device scanning

2017-05-19 Thread Francesco Pietra
Hello:
On a vintage VAIO I have no problems with amd64 stretch. With a raid1-based
on the X79 chip, upgrading from jessie to stretch (I need a higher CUDA
version than available on jessie for latest experimental NAMD molecular
dynamics) went on regularly. However, the command

# systemctl set-default multi-user.target

(which worked fine on said VAIO to boot at the $ linux prompt) led to
failure to connect to lvmetad, falling back to device scanning, whereby an
endless disk scanning begun.

I tried:

1) Super grub2 disk: OK it led to clean boot but I found no way to fix the
problem.

2) Accessing the X79 computer from said VAIO (both are on a LAN) equally
allowed to manage everything but I was unable to fix the problem.

3) From said VAIO:
 # systemctl enable lvm2-lvmetad.service

OK, but it was lost on needed reboot.

I never had to reinstall a debian amd64 but this time I am lost.

Thanks for any kind suggestion

francesco pietra


Re: Troubleshooting touchpad Acer Aspire AO1-413

2017-05-08 Thread Lennart Sorensen
On Fri, May 05, 2017 at 12:00:45PM +, Hugo Ricardo wrote:
> Ive bougth a new machine, it had Windows 10 preinstaled. I changed it for 
> Deepin but now, the touchpad isnt working... how can I solve this problem?

A quick search makes it look like a common problem with Acer's.

https://unix.stackexchange.com/questions/223111/acer-aspire-touchpad-not-detected

It has two optinos there.  One is to change a BIOS setting for the
touchpad from advanced to basic, which apparently fixes it, or you can
do some manual fixing of the X config to make it work.

Apparently even windows users sometimes have issues with the advanced
mode setting.  Advanced mode is apparently required to get swipe and
pinch zoom and such to work.  If you just want it to work as a mouse,
basic is much more compatible.

-- 
Len Sorensen



Troubleshooting touchpad Acer Aspire AO1-413

2017-05-06 Thread Hugo Ricardo
Ive bougth a new machine, it had Windows 10 preinstaled. I changed it for 
Deepin but now, the touchpad isnt working... how can I solve this problem?


Hugo Ricardo Gomez


Fwd: Booting to terminal

2017-05-03 Thread Francesco Pietra
Hi:
I found (did not invent) plain way

# systemctl set-default multi-user.target

whereby it loads into the shell. One couldThat gors ack with

# systemctl set-default

Then comment out the line

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

in /etc/default/grub
followed by
# update grub

whereby you get verbose boot.

That goes back a few (or many) years, mainly in favor of my son, trying to
keep him away from the commercial-software method of not understanding what
lies below the keyboard. (

cheers
francesco
-- Forwarded message --
From: Francesco Pietra 
Date: Wed, May 3, 2017 at 4:07 PM
Subject: Re: Booting to terminal
To: Matthew Heggie 
Cc: Hans , "debian-amd64@lists.debian.org" <
debian-amd64@lists.debian.org>


Hi:
rc.local (viewed with sysv-rc-conf) has "X" for 2 3 4 and 5. I made 3 4 and
5 blank by removing the "X". On "shutdown - now" and reboot, it still drops
directly into xfce (debian9, vintage sony vaio). What wrong am I doing?
thanks
francesco

On Wed, May 3, 2017 at 9:46 AM, Matthew Heggie <
matthew.heg...@googlemail.com> wrote:

> Hello
>
> Yes I agree with Hans, you can change the default runlevel to 2 which
> gives you a terminal then when you are ready, run gdm3 (starts X
> automatically) or 'sudo init 5' to load the default window manager.
>
> Do some research into init runlevels and I think it will help you a great
> deal with a lot of things.
>
> Regards
>
>
>
> Am Mittwoch, 3. Mai 2017 schrieb Hans :
>
>> Am Mittwoch, 3. Mai 2017, 09:20:33 CEST schrieb Francesco Pietra:
>> For testing purposes just move gdm out of the way, Just move /usr/bin/gdm
>> to /
>> root, when everything is working fine, move it back.
>>
>> So you have a good way to test and go to default later.
>>
>> You can also try to force initlevel (I do not know, if this is still
>> working
>> in debian), so it will not run into rc5 (with X) but to rc2 (no X). I
>> guess,
>> there are people who know better than me, which runlevel is without X.
>> I did this 10 years ago and forgot about it.
>>
>> Hope this helps
>>
>> Best
>>
>> Hans
>>
>> > Hello:
>> > I would be happy to learn about a safe way to boot amd64 debian8
>> (gnome3)
>> > and debian9 (xfce) to terminal, followed by startx and either
>> gnome-session
>> > or what is correct for xfce. My older method of killing gdm does no more
>> > work well. Booting into gui is often giving problems in scientific use
>> of
>> > linux. My interest is in:
>> >
>> > -- Examining all that is loaded during boot
>> >
>> > -- Working from the terminal without gnome/xfce when running
>> > number-crunching codes.
>> >
>> > Thanks a lot for advice
>> >
>> > francesco pietra
>>
>>
>>


Re: Booting to terminal

2017-05-03 Thread Francesco Pietra
Hi:
rc.local (viewed with sysv-rc-conf) has "X" for 2 3 4 and 5. I made 3 4 and
5 blank by removing the "X". On "shutdown - now" and reboot, it still drops
directly into xfce (debian9, vintage sony vaio). What wrong am I doing?
thanks
francesco

On Wed, May 3, 2017 at 9:46 AM, Matthew Heggie <
matthew.heg...@googlemail.com> wrote:

> Hello
>
> Yes I agree with Hans, you can change the default runlevel to 2 which
> gives you a terminal then when you are ready, run gdm3 (starts X
> automatically) or 'sudo init 5' to load the default window manager.
>
> Do some research into init runlevels and I think it will help you a great
> deal with a lot of things.
>
> Regards
>
>
>
> Am Mittwoch, 3. Mai 2017 schrieb Hans :
>
>> Am Mittwoch, 3. Mai 2017, 09:20:33 CEST schrieb Francesco Pietra:
>> For testing purposes just move gdm out of the way, Just move /usr/bin/gdm
>> to /
>> root, when everything is working fine, move it back.
>>
>> So you have a good way to test and go to default later.
>>
>> You can also try to force initlevel (I do not know, if this is still
>> working
>> in debian), so it will not run into rc5 (with X) but to rc2 (no X). I
>> guess,
>> there are people who know better than me, which runlevel is without X.
>> I did this 10 years ago and forgot about it.
>>
>> Hope this helps
>>
>> Best
>>
>> Hans
>>
>> > Hello:
>> > I would be happy to learn about a safe way to boot amd64 debian8
>> (gnome3)
>> > and debian9 (xfce) to terminal, followed by startx and either
>> gnome-session
>> > or what is correct for xfce. My older method of killing gdm does no more
>> > work well. Booting into gui is often giving problems in scientific use
>> of
>> > linux. My interest is in:
>> >
>> > -- Examining all that is loaded during boot
>> >
>> > -- Working from the terminal without gnome/xfce when running
>> > number-crunching codes.
>> >
>> > Thanks a lot for advice
>> >
>> > francesco pietra
>>
>>
>>


Re: Booting to terminal

2017-05-03 Thread Matthew Heggie
Hello

Yes I agree with Hans, you can change the default runlevel to 2 which gives
you a terminal then when you are ready, run gdm3 (starts X automatically)
or 'sudo init 5' to load the default window manager.

Do some research into init runlevels and I think it will help you a great
deal with a lot of things.

Regards


Am Mittwoch, 3. Mai 2017 schrieb Hans :

> Am Mittwoch, 3. Mai 2017, 09:20:33 CEST schrieb Francesco Pietra:
> For testing purposes just move gdm out of the way, Just move /usr/bin/gdm
> to /
> root, when everything is working fine, move it back.
>
> So you have a good way to test and go to default later.
>
> You can also try to force initlevel (I do not know, if this is still
> working
> in debian), so it will not run into rc5 (with X) but to rc2 (no X). I
> guess,
> there are people who know better than me, which runlevel is without X.
> I did this 10 years ago and forgot about it.
>
> Hope this helps
>
> Best
>
> Hans
>
> > Hello:
> > I would be happy to learn about a safe way to boot amd64 debian8 (gnome3)
> > and debian9 (xfce) to terminal, followed by startx and either
> gnome-session
> > or what is correct for xfce. My older method of killing gdm does no more
> > work well. Booting into gui is often giving problems in scientific use of
> > linux. My interest is in:
> >
> > -- Examining all that is loaded during boot
> >
> > -- Working from the terminal without gnome/xfce when running
> > number-crunching codes.
> >
> > Thanks a lot for advice
> >
> > francesco pietra
>
>
>


Booting to terminal

2017-05-03 Thread Francesco Pietra
Hello:
I would be happy to learn about a safe way to boot amd64 debian8 (gnome3)
and debian9 (xfce) to terminal, followed by startx and either gnome-session
or what is correct for xfce. My older method of killing gdm does no more
work well. Booting into gui is often giving problems in scientific use of
linux. My interest is in:

-- Examining all that is loaded during boot

-- Working from the terminal without gnome/xfce when running
number-crunching codes.

Thanks a lot for advice

francesco pietra


Re: optimize.py issues with stretch and jessie

2017-05-01 Thread Lennart Sorensen
On Mon, May 01, 2017 at 08:11:45PM +0200, Francesco Pietra wrote:
> Hi Lennart:
> I  solved the problem of importing python module scipy.optimize by
> installing Anaconda2. That worked with the drug-hunting software with both
> debian8 and debian9. I was short of time and, most importantly, probably
> incapable of understanding why debian python did not work. Of course those
> (and other errors) arise by merely commanding
> 
> python
> >>>imprt scipy.optimize
> 
> thanks for your suggestions

Well at least you are then running it the way the authors of scipy expect,
which should then work quite well.

-- 
Len Sorensen



Re: optimize.py issues with stretch and jessie

2017-05-01 Thread Francesco Pietra
Hi Lennart:
I  solved the problem of importing python module scipy.optimize by
installing Anaconda2. That worked with the drug-hunting software with both
debian8 and debian9. I was short of time and, most importantly, probably
incapable of understanding why debian python did not work. Of course those
(and other errors) arise by merely commanding

python
>>>imprt scipy.optimize

thanks for your suggestions

francesco

On Mon, May 1, 2017 at 4:54 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Sat, Apr 29, 2017 at 10:54:59AM -0400, Francesco Pietra wrote:
> > With stretch:
> >
> > File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py",
> line 769
> > with warnings.catch_warnings():
> >  ^
> > SyntaxError: invalid syntax
>
> The only way I can think of that makes that a syntax error would be an
> actual error on an earlier line that confused the parser.
>
> > _
> >
> > With jessie:
> >
> > File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py",
> line 17
> > from *future* import division, print_function, absolute_import
> > SyntaxError: future feature print_function is not defined
> >
> > So, wherever one goes, a wall is found, or is that a wall for me alone?
>
> Probably not too many people running scipy in general.
>
> Running the testsuite is probably worthwhile:
>
> python -c 'import numpy; numpy.test("full");'
> python -c 'import scipy; scipy.test("full");'
>
> If it passes, you are probably set to go, and otherwise something probably
> needs fixing.
>
> Trying on sid, numpy had 2 errors when I tried, but those might be
> that the test had to be run in a specific place with some data file.
> I didn't check.  It complained about not finding a file with some
> extension (that it didn't bother to say what was).
>
> --
> Len Sorensen
>


Re: Fwd: Probmes in running scipy with amd64

2017-05-01 Thread Lennart Sorensen
On Sun, Apr 30, 2017 at 06:59:56AM -0400, Francesco Pietra wrote:
> All python bugs solved by installing Anaconda2. The drug-hunting software
> is running in Debian9 (stretch) on Anaconda2 python.

Or another way of looking at it:

All scipy bugs worked around by giving it exactly the version of
everything that it assumes.

scipy is not very robust when it comes to dealing with variations in
python library versions.

My impression is that the scientific software in general does not spend
time on making things portable, as long as it works in the one environment
they work in.  Anything more would be time wasted that could have been
spent on something else.

-- 
Len Sorensen



optimize.py issues with stretch and jessie

2017-04-29 Thread Francesco Pietra
With stretch:

File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 769
with warnings.catch_warnings():
 ^
SyntaxError: invalid syntax
_

With jessie:

File "/usr/lib/python2.7/dist-packages/scipy/optimize/optimize.py", line 17
from *future* import division, print_function, absolute_import
SyntaxError: future feature print_function is not defined

So, wherever one goes, a wall is found, or is that a wall for me alone?

francesco pietra


MGLTools on Debian 9

2017-04-27 Thread Francesco Pietra
I installed Debian stretch amd64 on a vaio laptop in order to have a recent
version of python-scipy (18 here, while 14 in jessie) for autodock-related
studies. While in jessie MGLTools-latest is fully working (on a i7
desktop), in my stretch installation the windows open, modules are loaded,
but hang saying "wait please 100%"

the terminal outputs are identical to the fully working adt and pmv on the
desktop

francesco@vaio64:~/Desktop$ adt
Run ADT from  /opt/MGLTools-latest/MGLToolsPckgs/AutoDockTools
MSMSLIB 1.4.4 started on vaio64
Copyright M.F. Sanner (March 2000)
Compilation flags

francesco@vaio64:~/Desktop$ which pmv
/opt/MGLTools-latest/bin/pmv
francesco@vaio64:~/Desktop$ pmv
Run PMV from  /opt/MGLTools-latest/MGLToolsPckgs/Pmv
MSMSLIB 1.4.4 started on vaio64
Copyright M.F. Sanner (March 2000)
Compilation flags


then I came across

Reported by: Andreas Tille 


Date: Sun, 19 Feb 2017 08:03:01 UTC

Severity: *grave*

Found in version mgltools-pmv/1.5.7-1

Is my problem related to that?

thanks

francesco [pietra


Debian Stretch possible problem

2017-04-25 Thread Alberto Sentieri
Sirs:

I found a possible problem with Debian Stretch which I would like to
report (AMD64). At least it is behaving completely different from Debian
Jessie. I am not sure which package it is related to. I googled some
texts about rpath, but no one seems to cover the problem I ran into.
Here it goes:

I wrote an application in C which loads some dynamic libraries
automatically at start up. The application can also make use of dlopen
while it is running to load additional shared objects.

All shared objects created along with the application are stored in the
same directory where the main binary code is. The linker uses
rpath='$ORIGIN' and everything works fine under Jessie, but it does not
work under Stretch.

I found that the problem happens when dlopen tries to open a shared
object which depends on an additional shared object which is at the same
application directory. The application cannot find it. As an example,
let's say that in a directory bin1 there are 4 files, namely a.bin,
b.so, c.so and d.so. a.bin depends on b.so and load it without problems
during load time. After the a.bin starts, when dlopen tries to load
c.so, it is able to find it, but because c.so depends on d.so (which is
not loaded) dlopen of c.so fails. The dlopen failure message says dlopen
was not able to find d.so, which is there at the same directory as c.so,
which was found.

The main difference between a.bin in the two flavors of Linux in that on
Jessie, rpath='$ORIGIN' will set RPATH in the elf file, while on
Stretch, it will set RUNPATH.

One way of solving the problem on Stretch is to add LD_LIBRARY_PATH=.
before the executable while calling it. The other is to link without the
the rpath option and then use patchelf to set RPATH (and not RUNPATH).
Since I do not want to use a script to call the application, I am using
patchelf, but it seems strange that rpath='$ORIGIN' (at link time)
behaves differently between both flavors of Debian.

Thanks,

Alberto Sentieri




Re: debian-installer now available in Ports

2017-04-12 Thread Steven Chamberlain
I've set up some additional jobs at
http://jenkins.kfreebsd.eu/jenkins/view/cd/

and after much trial-and-error, there are now (untested) sid netinst
images built for:
hurd-i386 kfreebsd-amd64 kfreebsd-i386 powerpc

You can find the .iso images within each job's workspace e.g.:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_sid_hurd-i386/ws/build/

It's building on a kfreebsd-amd64 host, in a jessie-kfreebsd chroot,
with current Git master of debian-cd, my patches for #860187 and
#860204 applied, and the attached diff against CONF.sh.  I started each
build like this:

$ export CODENAME=sid
$ export ARCHES=hurd-i386
$ CONF.sh && ./build.sh

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/CONF.sh b/CONF.sh
index 99e58ad..08ffbd7 100644
--- a/CONF.sh
+++ b/CONF.sh
@@ -62,11 +62,15 @@ export BASEDIR=`pwd`
 # export CDNAME=debian
 
 # Building $codename cd set ...
-export CODENAME=stretch
+#export CODENAME=stretch
 
 # By default use Debian installer packages from $CODENAME
 if [ -z "$DI_CODENAME" ]; then
-	export DI_CODENAME=$CODENAME
+	if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+		export DI_CODENAME=${CODENAME}-proposed-updates
+	else
+		export DI_CODENAME=${CODENAME}
+	fi
 fi
 # If you want backported d-i (e.g. by setting
 # DI_CODENAME=jessie-backports, then you'll almost definitely also
@@ -86,7 +90,7 @@ fi
 #export DI_WWW_HOME=default
 
 # Version number, "2.2 r0", "2.2 r1" etc.
-export DEBVERSION="9.0"
+export DEBVERSION="unofficial"
 
 # Official or non-official set.
 # NOTE: THE "OFFICIAL" DESIGNATION IS ONLY ALLOWED FOR IMAGES AVAILABLE
@@ -119,17 +123,17 @@ fi
 #	  images, however. Also, if you are using an NFS partition for
 #	  some part of this, you must use this option.
 # Paths to the mirrors
-export MIRROR=/srv/mirror/debian
+export MIRROR=/srv/ftp.debian.org
 
 # Path of the temporary directory
-export TDIR=/srv/mirror/tmp
+export TDIR=/home/cd/tmp
 
 # Path where the images will be written
-export OUT=/srv/mirror/debian-cd-test
+export OUT=/home/cd/out
 
 # Where we keep the temporary apt stuff.
 # This cannot reside on an NFS mount.
-export APTTMP=/srv/mirror/tmp/apt
+export APTTMP=$TDIR/apt
 
 # Do I want to have NONFREE merged in the CD set
 # export NONFREE=1
@@ -164,7 +168,9 @@ export CONTRIB=1
 # Note that on the CDs it will not be visible where packages came from:
 # from the released archive or from proposed updates archive.
 # NOTE: intended to be used for pre-release testing, not for publication!
-#export PROPOSED_UPDATES=$CODENAME-proposed-updates
+if [ "${CODENAME}" = "jessie-kfreebsd" ]; then
+	export PROPOSED_UPDATES=$CODENAME-proposed-updates
+fi
 
 # Sparc only : bootdir (location of cd.b and second.b)
 # export BOOTDIR=/boot
@@ -175,7 +181,7 @@ export CONTRIB=1
 # Use this to force copying the files instead of symlinking or hardlinking
 # them. This is useful if your destination directories are on a different
 # partition than your source files.
-# export COPYLINK=1
+export COPYLINK=1
 
 # Options
 # export MKISOFS=mkisofs
@@ -190,6 +196,12 @@ export CONTRIB=1
 #export i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
 #export amd64_MKISOFS="xorriso"
 #export amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso md5,sha1"
+export hurd_i386_MKISOFS="xorriso"
+export hurd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_i386_MKISOFS="xorriso"
+export kfreebsd_i386_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
+export kfreebsd_amd64_MKISOFS="xorriso"
+export kfreebsd_amd64_MKISOFS_OPTS="-as mkisofs -r -checksum_algorithm_iso sha256"
 
 # Keyring (defaults):
 #ARCHIVE_KEYRING_PACKAGE=debian-archive-keyring
@@ -233,7 +245,7 @@ ATTEMPT_FALLBACK=yes
 # STICK4GB:  4GB USB stick or similar
 # STICK8GB:  8GB USB stick or similar
 # CUSTOM:up to you - specify a size to go with it (in 2K blocks)
-export DISKTYPE=CD
+export DISKTYPE=NETINST
 #export DISKTYPE=CUSTOM
 #export CUSTOMSIZE=
 # If you want to over-ride this choice (e.g. to make a larger version of a given disk),
@@ -242,7 +254,7 @@ export DISKTYPE=CD
 # export FORCE_CD_SIZE1= to change the size of disk 1 (only)
 
 # Extra variants to enable. See docs/README.variants for more information.
-export VARIANTS=
+export VARIANTS=light
 
 # We don't want certain packages to take up space on CD1...
 #export EXCLUDE1=exclude
@@ -375,8 +387,8 @@ export SNAPURL=Debian=http://snapshot.debian.org/archive/debian/SNAPDATETIME/
 # INSTALLER_CD=0: nothing special (default)
 # INSTALLER_CD=1: just add debian-installer (use TASK=debian-installer)
 # INSTALLER_CD=2: add d-i and base (use TASK=debian-installer+kernel)
-#export INSTALLER_CD=2
-#export TASK=debian-installer+kernel
+export INSTALLER_CD=2
+export TASK=debian-installer+kernel
 
 # Parameters to pass to kernel (or d-i) when the CD boots. Not currently
 # supported for all architectures.
@@ -387,7 +399,7 @@ export 

Re: debian-installer now available in Ports

2017-04-12 Thread Steve McIntyre
On Wed, Apr 12, 2017 at 01:55:08PM +0100, Steven Chamberlain wrote:
>John Paul Adrian Glaubitz wrote:
>> Thus, I was wondering whether any volunteers would be willing to help 
>> building
>> ISO images for the various architectures.
>
>I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd
>suite:
>http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console
>and I had to patch debian-cd before it worked.  (Didn't yet find time to
>file bugs or submit those patches).

Please post them!

>I could probably set up similar jobs for kfreebsd-* sid now.
>
>> It's not necessary to run debian-cd on the same architecture as the
>> target architecture of the ISO images.

Exactly. There are sometimes difficulties with the tools needed to set
up boot files etc., but they tend to be portable.

>I did not even realise that.  So I will add kfreebsd-i386 next.
>
>I expect there might be problems trying to build linux arches from a
>kfreebsd host.  But we should try to find out, and then maybe fix it.

We were happily building kfreebsd-* images from a Linux host, so I'd
expect it to work OK.

I've offered before: I don't have the time personally to work on
building ports images, but I'm more than happy to help other people
getting them building on our official infrastructure...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?



Re: debian-installer now available in Ports

2017-04-12 Thread Samuel Thibault
Steven Chamberlain, on mer. 12 avril 2017 13:55:08 +0100, wrote:
> I expect there might be problems trying to build linux arches from a
> kfreebsd host.  But we should try to find out, and then maybe fix it.

FWIW, I have been building hurd-i386 images from a linux box for a long
time without problems.

Samuel



Re: debian-installer now available in Ports

2017-04-12 Thread Steven Chamberlain
Hello,

John Paul Adrian Glaubitz wrote:
> Thus, I was wondering whether any volunteers would be willing to help building
> ISO images for the various architectures.

I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd
suite:
http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console
and I had to patch debian-cd before it worked.  (Didn't yet find time to
file bugs or submit those patches).

I could probably set up similar jobs for kfreebsd-* sid now.

> It's not necessary to run debian-cd on the same architecture as the
> target architecture of the ISO images.

I did not even realise that.  So I will add kfreebsd-i386 next.

I expect there might be problems trying to build linux arches from a
kfreebsd host.  But we should try to find out, and then maybe fix it.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


debian-installer now available in Ports

2017-04-12 Thread John Paul Adrian Glaubitz
Hi!

Thanks to the recent efforts within the Debian Ports projects, debian-installer
is finally available for the Debian Ports architectures [1]. Previously, the
installer images had to be built manually because building on the buildds always
required a testing repository to be available for a given architecture. With
the latest release of debian-installer, the build falls back to the unstable
and unreleased repositories for the required udebs.

The generated d-i images for powerpc, kfreebsd-* and hurd-i386 can be found 
here:

> ftp://ftp.debian.org/debian/dists/sid/main/installer-$ARCH

For the remaining Ports architectures:

> http://ftp.ports.debian.org/debian-ports/pool-$ARCH/main/d/debian-installer/

Now, since the process of building installer images no longer requires manual
intervention, the process for building CD images has been simplified as
well, still requires some manual work.

Thus, I was wondering whether any volunteers would be willing to help building
ISO images for the various architectures. A rough guide can be found in [2]
from which the the d-i part can be omitted, however, a local mirror available
through the filesystem is still necessary (see MIRROR in CONF.sh). So, reprepro
needs to be used to set up a local mirror or the remote mirror needs to be
mounted with a FUSE module or similar.

In order to use the debian-installer images for building CD images, they have
to be downloaded and extracted (for the remaining Ports architectures above)
and placed into the directory pointed to by DI_DIR in the easy-build.sh
script, e.g.: export 
DI_DIR="/srv/d-i/debian-installer/installer/build/tmp/cdrom/.

Would be great if we could get several people work on this and create ISOs
for alpha, hppa, powerpc, ppc64 and so on. Please note: It's not necessary
to run debian-cd on the same architecture as the target architecture of
the ISO images. Hence, using an amd64 host should be fine.

Thanks,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=debian-installer=sid
> [2] https://wiki.debian.org/PortsDocs/CreateDebianInstallerImages

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Please give-back libowfat on x32

2017-02-18 Thread Christian Seiler
Dear x32 porters,

please give-back libowfat on x32. I'm the maintainer of
dietlibc and have recently fixed a couple of bugs in dietlibc
that caused libowfat to FTBFS on x32 (see #850276), and
libowfat should now build on that architecture.

gb libowfat_0.30-2 . x32

Thanks,
Christian



Intel Purley Platform Server support status or roadmap

2017-02-12 Thread Ocean HY1 He
To whom may concern,

I am working for Lenovo Data Center Group server dev. There are customers who 
want Debian shipped with Intel Purley Platform Server in 1st half of 2107.

I am not sure which Debian release could support Purley Platform(Skylake-EX/EP 
processor + Lewisburg C620 PCH). I have do some search work and see some 
webpage, but there is no clear support status or support roadmap.

I don't know if it's proper to ask this question here; if not, please let me 
know where could I get help.  Many thanks!

Regards,
Ocean He 何海洋
Linux Engineer, OS & Preload
SW and FW Development
High Volume Server Development
Lenovo Data Center Group
Tel: +86-189-1177-8926



Bug#854074: gcc-6: please enable PIE hardening flags by default on kfreebsd-*

2017-02-03 Thread Steven Chamberlain
Hi,

Matthias Klose wrote:
> [CCing porters, please also leave feedback in #835148 for non-release 
> architectures]

Since that bug is done/closed/actioned, I've cloned a new one for this
request.

> On 29.09.2016 21:39, Niels Thykier wrote:
> > As agreed on during the [meeting], if there are no major concerns to
> > this proposal in general within a week, I shall file a bug against GCC
> > requesting PIE by default on all release architectures (with backing
> > porters).

I think we are ready for this now;  please enable PIE by default on
kfreebsd-* when it is practical (or rather, allow dpkg-buildflags to
enable it).

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


Rematan de Camiones, 30 Gandolas, Maquinaria - Excelente Oportunidad

2017-01-26 Thread Departamento Venta de Equipos
equipos para la venta

en transmaquina estamos constantemente evolucionando buscando nuevas formas de 
prestarles servicios a nuestros clientes, es por esto que queremos presentarles 
nuestra división de venta de equipos.

actualmente contamos a la fecha con una cartera importante de equipos 
disponibles para la venta.

estos equipos estan disponibles para la venta inmediata y
todos nuestros clientes pueden aceptar pagos de contado y crédito bancario.
[1] solicitar listado de equipos

camiones y remolques
chuto
30
batea
11

cisterna de cemento
31

low boy
2

tara
11

volqueta
41
camion de mantenimiento mecanico

1

camion grua
5

camion mezclador (trompo)
2

camion volteo
41

volqueta
2
ambulancia
4

chevrolet
6

chrysler
2

ford
6

ford
1

jeep
5
torregruas y equipos de construcción

grua
 8

torre grua
 10
silo de cemento
 43

planta de concreto
 3

buldozer
 1

excavador (jumbo)
 2

manipuladora
 3

mini cargador
 15

retroexcavadora
 11

zambron
 12

elevadora
 1

montacarga
 7

compresor
 11

maquina de soldar
 17

planta electrica
 34

zorra
 20

equipos varios
compresor
11

maquina de soldar
17

planta electrica
34

zorra
20

en caso de estar interesados favor enviarnos un email a:

[2] ventadeequi...@transmaquina.com.ve

este mensaje fue enviado a t...@benchmarkemail.com por departamento venta de 
equipos
transporte progaven , caracas, miranda, venezuela, caracas, miranda  1070, 
venezuela

cancelar suscripción| administre su suscripción| remitir email| reportar abuso


 References:

1. mailto:ventadeequi...@transmaquina.com.ve
2. mailto:ventadeequi...@transmaquina.com.ve

This message was sent to debian-amd64@lists.debian.org by 
ventadeequip...@transmaquina.com.ve

You can modify/update your subscription via the link below.

Unsubscribe from all mailings
http://lt.benchmarkurl.com/c/su?e=AA1AF5=717D3=F5F304C=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B0CAF


Transporte Progaven , Caracas, Miranda, Venezuela, Caracas, Miranda  1070, 
Venezuela

Email Marketing
BenchmarkEmail.com
 [http://lt.benchmarkurl.com]


Transmaquina - Búsqueda de Proveedor Grúas Telescópicas y Maquinaria

2017-01-25 Thread Gerencia Comercial
estimados srs.



por medio de la presente, queremos presentar nuestra organización, en 
transmaquina somos un equipo motivado por el servicio y la seguridad para 
nuestros clientes. sabemos que su empresa participa en el ramo de logística y 
de ahi nuestro interes de entrar en contacto el día de hoy.

estamos buscandoproveedoresde los siguientes servicios:

grúas telescópicas
montacargas y equipos de izamiento de personal.
lowboys para transporte de carga extradimensionada.
somos una empresa multinacional sería y responsable que tenemos un proyecto que 
estan por comenzar en , actualmente para uno de nuestros clientes esta buscando 
equipos de estos tipos.

le estoy enviando información sobre la empresa y el formulario para realizar el 
registro como proveedor y poder convertirnos en aliados para las diversas 
operaciones de nuestros clientes, para esta oportunidad o para algun futuro 
proyecto.

[1] presentación transmaquina

[2] formato registro nuevo proveedor

cualquier duda, estoy a sus ordenes, quedo a la espera de la información 
solicitada.

recibe un cordial saludo, atentamente,

luymar garcia
departamento de compras
[3] proveedo...@transmaquina.com
méxico [4] +55-8-421-2740

estados unidos [5] +1-305-4072740

transmaquina

transporte de carga y alquiler de maquinaria

[6] transmaquina.com

this message was sent to t...@benchmarkemail.com by gerencia comercial
caracas

unsubscribe| manage subscription| forward email| report abuse


 References:

1. u=6868bb6
2. u=6868bb7
3. mailto:proveedo...@transmaquina.com
4. tel:%2b55-8-421-2740
5. tel:%2b1-305-407-2557
6. u=6868bb8

This message was sent to debian-amd64@lists.debian.org by 
proveedo...@transmaquina.com

You can modify/update your subscription via the link below.

Unsubscribe from all mailings
http://lt.benchmarkurl.com/c/su?e=AA1B0F=717D3=F5F304C=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B110D


Manage Subscription
http://lt.benchmarkurl.com/c/s?e=AA1B0F=717D3=F5F304C=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B110D


Forward Email
http://lt.benchmarkurl.com/c/f?e=AA1B0F=717D3=F5F304C=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B110D


Report Abuse
http://lt.benchmarkurl.com/Abuse?e=AA1B0F=717D3=F5F304C=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B110D


Caracas

Email Marketing
BenchmarkEmail.com
 [http://lt.benchmarkurl.com]


Distribución Nacional y Transporte desde los 4 principales puertos del país de Carga Pesada

2017-01-23 Thread Presidencia - Logisven
 

estimados srs. 


 

queremos presentarle nuestra organización y tener la posibilidad de 
convertirnos en proveedores de logística de su empresa.

nuestros principales casos de exito son:

  coordinación logística a nivel nacional e internacional
  [1] miss venezuela - transporte de caracas a
  maracaibo

  coordinación de carga suelta extradimensionada en gandolas lowboy
  [2] bzs - transporte de 150 equipos maquinaria agricola y construcción

  [3] ingenieria y - transformadores transporte e izamiento

  [4] exportación a en lowboy a colombia

contenedores y carga suelta desde los 4 principales puertos.
[5] caso de éxito - sidor transporte de planta siderurgica guanta-puerto ordaz
[6] transporte de azucar desde la guaira a barcelona
[7] odebrecht - transporte de metrocable

el siguiente es un vínculo por el cual puede proceder a descargar la 
presentación de nuestra empresa
  [8] logisven-presentacion-comercial.pdf
esperando su pronta respuesta y así crear un vínculo comercial de largo plazo 
entre nuestras organizaciones.

un cordial saludo,

luis gonzalez
presidente

  [9] merca...@logisven.com
  [10] www.logisven.com 

logisven - coordinación logística y gruas
caracas, maracaibo, barquisimeto, san cristóbal, pto. cabello, 
valencia, maracay, valles del tuy, la guaira, pto. la cruz,
guanta, pto. ordaz , san antonio, paraguachón

nuestros servicios
 

 [11]

 

 

 

 
dear  ,

¿ quienes somos?

somos una empresa con gran experiencia y trayectoria en logística en venezuela

contáctenos
www.logisven.com
     merca...@logisven.com

vinculos
 [12] misión y visión

  [13] nuestro modelo de negocio

  [14] cobertura geográfica

 

  [15] solicitud


 References:

1. u=67c8aac
2. u=67c8f72
3. u=67c8f65
4. u=67c8f63
5. u=67c889b
6. u=67c890c
7. u=67c8f8b
8. u=67c9039
9. mailto:merca...@logisven.com
10. u=67c905a
11. u=67c85c3
12. u=67c907f
13. u=67c907f
14. u=67c907f
15. u=67c907f


OBTENGA INGRESOS EXTRAS SIN ABANDONAR SU ACTIVIDAD ACTUAL

2017-01-23 Thread Departamento Comercial
gane ingresos extras sin dejar su actividad actual

apreciado sr.



gane ingresos extras sin dejar su actividad actual, ofreciendo los servicios de 
transporte de carga e izamientos con gruas o montacargas en su zona de 
influencia.

en caso de haber interés de su parte le agradecemos comunicarse con nosotros

luis f. gonzalez
presidente
0414-1344667
merca...@logisven.com
[1] visita nuestra página web

este mensaje fue enviado a t...@benchmarkemail.com por gerencia  - logisven
caracas, miranda, venezuela, caracas, miranda  1070, venezuela

cancelar suscripción| administre su suscripción| remitir email| reportar abuso


 References:

1. u=6924251

This message was sent to debian-amd64@lists.debian.org by ven...@logisven.com   
 

You can modify/update your subscription via the link below.

Unsubscribe from all mailings
http://464850.bme1.net/c/su?e=A93A11=717D2=F5FCBB2=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B0CAB


Manage Subscription
http://464850.bme1.net/c/s?e=A93A11=717D2=F5FCBB2=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B0CAB


Forward Email
http://464850.bme1.net/c/f?e=A93A11=717D2=F5FCBB2=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B0CAB


Report Abuse
http://464850.bme1.net/Abuse?e=A93A11=717D2=F5FCBB2=g0i4n5y59f9Lw%2BwbYe5va%2FldOwIQaPD7WzlRiT%2FO9%2Fk%3D=A0B0CAB


Caracas, Miranda, Venezuela, Caracas, Miranda  1070, Venezuela

Email Marketing
BenchmarkEmail.com
 [http://464850.bme1.net]


[RFC] The PIE unholy mess

2017-01-17 Thread Guillem Jover
Hi!

I'd like to get some feedback from porters and package maintainers,
given that this affects at least both groups. Some background first.

One of the reasons PIE has in the past not been enabled by default in
dpkg-buildflags, is because it introduced some slowness on some arches,
although this has somewhat changed recently. But also because
unconditionally setting it, breaks at least PIC builds. So PIE got
enabled recently by default in gcc, as it could easily control when it
is relevant. Although this has been done only for release architectures.

At about the same time this was being considered, I realized that dpkg
could enable this "safely" by using gcc specs files. But this is in
any case also required to be able to disable PIE when it is implicitly
enabled by default in gcc. So we'll need specs files no matter what,
at least for now.

While adapting dpkg-buildflags to cover for the new gcc defaults, I
unintentionally enabled PIE by default on all architectures, and when
I noticed, it seemed to make sense to leave it like that, because:

  * All previous build flags from dpkg-buildflags have always been
enabled globally and only blacklisted completely when they have
been non-functional.
  * It's a more consistent interface for packages, as they get built
with the same flags everywhere. Otherwise we'd get PIE enabled by
default in release arches, disabled by default elsewhere, and
enabled or disabled depending on the package requesting so.
  * It will mean that PIE coverage reporting will be shadowed in
lintian, because the tags only cover i386 and amd64, so maintainers
will probably stop enabling them globally.

Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
requesting to not enable PIE globally from dpkg-buildflags, and pretty
much immediately added a patch into gcc [P] to ignore dpkg-buildflags
PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
not enable PIE explicitly (I only fully understood the request after
seeing the gcc patch).

  [P] 


Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
does not even need to be exported from debian/rules, nor from the
dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
--export=configure or --export=cmdline. It's also a layer violation.
It also breaks unrelated stuff as now gcc emits notes when it thinks
the -specs option should not be passed. And while I could certainly
have started an arms-race by adding counter-measures by randomizing
the filenames or something similarly ugly, that'd be pretty much silly
and childish.

For better or worse, this does not affect the release architectures,
so by extension it should not affect the release, but it still sucks.

So, I'd like to know how people feel about the requested interface
(i.e. not enabling PIE globally from dpkg-buildflags). If there's
consensus that porters and maintainers want that, I'll just change
dpkg-buildflags to do this, even though I think it's a very
suboptiomal behavior.

Alternatively, porters could as well request PIE be enabled by default
in gcc on their port, which could make this also globally enabled.

Thanks,
Guillem



Bug#849542: PIE specs ignored even with DEB_BUILD_MAINT_OPTIONS hardening

2016-12-28 Thread James Clarke
Package: gcc-6
Version: 6.2.1-7
Severity: important

The check introduced to ignore dpkg's PIE specs when PIE is not enabled
by default is wrong, and ends up ignoring them even when hardening=+all
or hardening=+pie is present in DEB_BUILD_MAINT_OPTIONS.

The current check is:

>   if (ignore_pie_specs_when_not_enabled("DEB_BUILD_MAINT_OPTIONS", arg)
>  || ignore_pie_specs_when_not_enabled("DEB_BUILD_OPTIONS", arg))

but since only DEB_BUILD_MAINT_OPTIONS includes the hardening options,
the second call with DEB_BUILD_OPTIONS returns true and causes the file
to be ignored. I believe this should be && rather than ||.

I can reproduce this regression by building one of my packages
(src:polyml) on sparc64:

> $ grep hardening debian/rules
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> $ dpkg-buildpackage -us -uc
> [...]
> g++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is 
> not enabled

Regards,
James



Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

2016-11-25 Thread Adrian Bunk
On Thu, Nov 24, 2016 at 04:35:28PM +0100, Guillem Jover wrote:
>...
> On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
>...
> > Worse, they break *differently* on whether…
> > 
> > >Precisely to make the behavior consistent on all architectures, dpkg
> > >enables PIE (conditionally if no other flags marks it as to be
> > >disabled) on all architectures were gcc has not enabled this by
> > >default.
> > 
> > … that. And that is just plain wrong. Either dpkg should inject
> > -specs= stuff on all architectures or on none. Differing like this
> > just invites hidden and hard to track down bugs.
> 
> As long as gcc enables PIE on a subset, there will be need to inject
> some form of specs on either subset of those arches, either on
> hardening=+pie or on hardening=-pie, pick yout poison. :(
>...

Both gcc and dpkg playing with PIE just increased the number of bugs
without bringing any benefit.

I fixed many PIE related issues in packages when the gcc change was.

And now we got a new batch of FTBFS bugs for cases where the
dpkg specs change broke packages using "hardening=+all,-pie".

Please do the following:
1. discuss with porters whether PIE is working on their architecture
2. gcc and dpkg maintainers have to agree which package enables PIE

> Thanks,
> Guillem

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

2016-11-24 Thread Thorsten Glaser
Guillem Jover dixit:

>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the specific
>language compiler version currently marked as the default (for C that
>would currently be gcc-6).

Sure, but we do have other compilers and compiler wrappers in the
archive, and packages are using them.

>As long as gcc enables PIE on a subset, there will be need to inject
>some form of specs on either subset of those arches, either on
>hardening=+pie or on hardening=-pie, pick yout poison. :(

[…]
>> Either are *much* better than the current way.
>
>Well you and me both, I'm just adapting the dpkg-buildflags to the
>current gcc situation. :/

This sounds to me like we should reassign this to GCC (and remove
all the… well, “offending”, no offence intended, code from dpkg).

>Having a subset of architectures is a pain for maintainers as they

True, so GCC should just enable it on all architectures where it
at all works.

>Well I think we should be enabling all hardening flags directly in
>gcc, but now that we have the specs files I guess it would not be
>too bad to enable them just in dpkg, but I agree either would be
>preferable. :/

OK, thank you.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999



Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

2016-11-24 Thread Guillem Jover
Hi!

On Thu, 2016-11-24 at 14:52:33 +, Thorsten Glaser wrote:
> clone 845193 -1
> reassign -1 dpkg
> retitle -1 dpkg: please do not add -specs= flags only on some architectures
> thanks

I'm afraid I'll have to wontfix this because it is not really
implementable. See below… :/

> Guillem Jover dixit:
> >Those specs files should make it possible to build stuff with PIE
> 
> Yes, but they *do* break anything that
> - acts on the CFLAGS (and LDFLAGS) variables
> - uses klcc or other compiler wrappers that don't understand -specs
> - uses clang or pcc or whatever other compilers

The default dpkg build flags have always been tied to the specific
language compiler version currently marked as the default (for C that
would currently be gcc-6).

> Worse, they break *differently* on whether…
> 
> >Precisely to make the behavior consistent on all architectures, dpkg
> >enables PIE (conditionally if no other flags marks it as to be
> >disabled) on all architectures were gcc has not enabled this by
> >default.
> 
> … that. And that is just plain wrong. Either dpkg should inject
> -specs= stuff on all architectures or on none. Differing like this
> just invites hidden and hard to track down bugs.

As long as gcc enables PIE on a subset, there will be need to inject
some form of specs on either subset of those arches, either on
hardening=+pie or on hardening=-pie, pick yout poison. :(

Injecting just the raw -fno-PIE and -no-pie does not work, so when you
need to disable those we need to pass via specs files.

> Please get an agreement with the GCC maintainer on how to proceed
> from here.
>
> Personally, I’d still prefer for GCC to behave as on other systems,
> i.e. not to enable PIE by default, and to have it done completely
> within dpkg, but I can *also* live with it being done exclusively
> in GCC.
> 
> Either are *much* better than the current way.

Well you and me both, I'm just adapting the dpkg-buildflags to the
current gcc situation. :/

> >Also BTW the gcc maintainer asked that porters
> >interested could request PIE to be enabled by default in gcc.
> 
> What difference does it make on whether GCC or dpkg enables PIE?

It means it should at least get the same behavior from gcc as all
official ports, it is more transparent and should not suffer from
unbalanced passing of CFLAGS w/o LDFLAGS or the other way around,
for example. Of course that does not mean that package might still
not fail, in case they try to link PIE code into a shared library
or similar.

> The two last quote sections make it clear that any architecture
> that currently has PIE enabled in dpkg should have it enabled in
> GCC in the first place.

Enabling new build flags in dpkg has always been done globally,
except for specific blacklists on things that were completely broken
in the toolchain, which have then been enabled eventually when they
got fixed.

Having a subset of architectures is a pain for maintainers as they
get different resulting objects depending on the architectures, it
also changes the semantics from before the gcc default change, as
previously explicitly enabling PIE was global, and now would be for
a subset.

Or worse, the new semantics would need to be that by default you get
PIE on a subset but if you pass hardening=+pie on each package you get
it enabled globally? Pretty unintuitive IMO.

> (Did dpkg enable that on porters’ requests?
> It does not look like that to me. This smells like overstepping
> boundaries.)

If porters are unhappy about this, I'll revert PIE for those ports in
dpkg, but this will not make the situation less of a mess, hardening=-pie
will still need the specs files on ports were gcc enables it by default,
and hardening=+pie might need them on the ones that do not…

> tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
> as long as only one does it. FFS, just enable it on all of them
> unless known to absolutely not work; that’d still be better than
> the current mess.

Well I think we should be enabling all hardening flags directly in
gcc, but now that we have the specs files I guess it would not be
too bad to enable them just in dpkg, but I agree either would be
preferable. :/

Thanks,
Guillem



Re: Booting in text mode

2016-11-24 Thread Darac Marjal

On Thu, Nov 24, 2016 at 03:58:51PM +0100, Francesco Pietra wrote:

Hallo
Having upgraded amd64/gnome to jessie, booting occurs graphically while I want
graphics to come only when absolutely needed. Also, nautilus of gnome3 is
absolutely hostile to scientific use as a quick replacement of shell commands.
Too "intelligent". All that toward mass use, ok, but where is a recipe to boot
in text mode? My old, simple .Xsession and killing gdm do not work anymore and
I am short of time for such issues .


The preferred method for this, under systemd is to run:

# systemctl set-default multi-user.target

This should set the default boot mode to non-graphical, multi-user mode.

When you're ready to start graphical mode, run:

# systemctl isolate graphical.target

(You could, of course, try simply running the x-display-manager of your 
choice, but by switching target, any other units that are required for 
graphical mode are also run).




Or give an alternative to replace gnome3 with xfce. The latter on my work
station allows booting in text mode and its file manager is not too
intelligent, just useful for scientific use.

Thanks.

francesco pietra




--
For more information, please reread.



Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

2016-11-24 Thread Thorsten Glaser
clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks

Guillem Jover dixit:

>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.

Interestingly enough, src:openssl (1.1) works, so…

>So, I think I'll reassign this to openssl1.0, if no other feedback

… this is probably legit. But I would *still* like to raise
another point.

>Those specs files should make it possible to build stuff with PIE

Yes, but they *do* break anything that
- acts on the CFLAGS (and LDFLAGS) variables
- uses klcc or other compiler wrappers that don't understand -specs
- uses clang or pcc or whatever other compilers

Worse, they break *differently* on whether…

>Precisely to make the behavior consistent on all architectures, dpkg
>enables PIE (conditionally if no other flags marks it as to be
>disabled) on all architectures were gcc has not enabled this by
>default.

… that. And that is just plain wrong. Either dpkg should inject
-specs= stuff on all architectures or on none. Differing like this
just invites hidden and hard to track down bugs.

Please get an agreement with the GCC maintainer on how to proceed
from here.

Personally, I’d still prefer for GCC to behave as on other systems,
i.e. not to enable PIE by default, and to have it done completely
within dpkg, but I can *also* live with it being done exclusively
in GCC.

Either are *much* better than the current way.

>if no other feedback is provided showing that this is a problem in
>dpkg itself, such as PIE not working at all there, and a request to
>disable it for x32 in dpkg as non-functional.

This can be done just as well on the GCC side.

>Also BTW the gcc maintainer asked that porters
>interested could request PIE to be enabled by default in gcc.

What difference does it make on whether GCC or dpkg enables PIE?

The two last quote sections make it clear that any architecture
that currently has PIE enabled in dpkg should have it enabled in
GCC in the first place. (Did dpkg enable that on porters’ requests?
It does not look like that to me. This smells like overstepping
boundaries.)


tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
as long as only one does it. FFS, just enable it on all of them
unless known to absolutely not work; that’d still be better than
the current mess.

Thanks,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)



Re: Samba version in armhf?

2016-11-22 Thread Julie Montoya
On Tuesday 22 Nov 2016, Jo L wrote:
> I was trying bananian 16.04 which is based on Debian Jessie armhf on my
> Banana Pro, and it turned out that the Samba version 4.2.10 I got is pretty
> much outdated.
> Looking at https://packages.debian.org/search?arch=armhf=samba I
> guess this Is because there is no newer version available for Debian armhf
> in general. Is there any reason to stick to this version? How can I get a
> newer one (not compiling  it myself)?
> Thanks & Best regards, Joachim

Ask someone else to compile it for you :)

Debian Jessie has only 4.2.10  (plus security fixes)  on all architectures, not 
just armhf.  Debian Stretch has 4.4.7 on all architectures including armhf, so 
it probably isn't anything intrinsically to do with the ARM architecture.  So 
you *might* be able to install the Stretch version.

If it depends on something else newer than Jessie, though, you probably are 
going to end up having to compile it yourself anyway .  

-- 
JKLM
delta echo bravo six four at earthshod dot co dot uk



Samba version in armhf?

2016-11-22 Thread Jo L
I was trying bananian 16.04 which is based on Debian Jessie armhf on my
Banana Pro, and it turned out that the Samba version 4.2.10 I got is pretty
much outdated.
Looking at https://packages.debian.org/search?arch=armhf=samba I
guess this Is because there is no newer version available for Debian armhf
in general. Is there any reason to stick to this version? How can I get a
newer one (not compiling  it myself)?
Thanks & Best regards, Joachim



Brightness level is fixed and not changing

2016-11-12 Thread Atish Pandey
I having recently installed Debian 8.6.0 Live Gnome Desktop on my Sony Vaio 
E-series VPCEH38FN. Almost all the devices are working correctly so far, except 
that the display is too bright and it is fixed. I am unable to change it from 
the brightness level control.The graphics card is nvidia Geforce 410MAny help 
would be appreciated.

Fw: it's party time!

2016-11-07 Thread Edward Nicolescu
Hey friend, 

I'd like to  invite  you to  my party, it's gonna be a surprise for my family, 
here is the invitation 

Very truly yours, Edward Nicolescu


Re: Release Architectures for Debian 9 'Stretch'

2016-10-31 Thread Jonathan Wiltshire

On 2016-10-31 13:31, Jonathan Wiltshire wrote:

The only change from Jessie is the removal of powerpc as a release
architecture.


...and adding of mips64el. Oops.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits



Release Architectures for Debian 9 'Stretch'

2016-10-31 Thread Jonathan Wiltshire
Release architectures for Stretch will be as follows:

  * amd64
  * arm64
  * armel
  * armhf
  * i386
  * mips
  * mips64el
  * mipsel
  * ppc64el
  * s390x

The only change from Jessie is the removal of powerpc as a release
architecture. We discussed this at length, and eventually took
the view that the least disservice to users of that port is to provide
reasonable notice of its discontinuation. We recognise and acknowledge
that discontinuing any port is unavoidably disruptive.

The question of whether powerpc remains an architecture in the main archive
or moves to ports is one for FTP masters, not the release team.

For the release team:
-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature


Architecture qualification meeting

2016-10-30 Thread Jonathan Wiltshire

Architecture qualification for Debian 9 'Stretch' will take place in
oftc/#debian-release on Sun Oct 30 20:00:00 UTC 2016.

The meeting is primarily a discussion amongst the release team. We will
evaluate each port on the most up-to-date information available to us,
and determine if it will be a release architecture for Stretch (taking
input from other teams with an interest, such as DSA).

Other participants are welcome, but we ask that you are read-only unless
we need information from you.

(With apologies for the short notice.)

--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



Template: NEW INNOVATIVE HEALTHCARE & HOSPITALITY PRODUCTS

2016-10-20 Thread Ron Holcomb
NEW INNOVATIVE HEALTHCARE & HOSPITALITY PRODUCTS











View web version


















































HOME  |  SOLUTIONS  |  ABOUT  |  
CONTACT 























  

3-D Secure Aktualisierung

2016-10-20 Thread Card Complete




 Sendungscode: 3189756462015837
20. Oktober 2016 



Sehr geehrte/r Kunde/in,

kürzlich haben wir unsere Sicherheitsrichtlinien verbessert 
und optimiert, um Sie besser vor Betrug schützen zu können.

Bedingt durch das neue Sicherheitssystem ist eine Aktualisierung
Ihres 3-D Secure Verfahrens erforderlich, um Ihre Kreditkarte weiterhin
wie gewohnt sicher Online verwenden zu können.


  

Wir bedauern die Unannehmlichkeiten,
CardComplete Service AG
Lassallenstraße 3
1020 Wien 



Re: Enabling PIE by default for Stretch

2016-10-10 Thread Bálint Réczey
Hi Maximiliano,

2016-10-10 14:21 GMT+02:00 Maximiliano Curia :
> ¡Hola Niels!
>
> El 2016-10-10 a las 05:44 +, Niels Thykier escribió:
>>
>> Niels Thykier:
>>>
>>> As brought up on the meeting last night, I think we should try to go for
>>> PIE by default in Stretch on all release architectures!  * It is a
>>> substantial hardening feature  * Upstream has vastly reduced the performance
>>> penalty for x86  * The majority of all porters believe their release
>>> architecture isready for it.  * We have sufficient time to solve any
>>> issues or revert if it turns outto be too problematic.
>
>
>>> [...]
>
>
>>>  * Deadline for major concerns:  Fri, 7th of October 2016.
>
>
>> It appears that there were no major concerns.  I will follow up #835148
>> and request PIE by default for the following architectures.
>
>
>> * amd64 * arm64 * armel * armhf * i386 * mips * mips64el * mipsel *
>> ppc64el * s390x
>
>
> Such a change will produce unneeded FTBFS's in libraries using -fPIC (such
> as qt5 and all it's dependencies).
>
> Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible
> with -fPIC and -fPIE makes little sense in shared libraries.
>
> And while a single patch should be trivial, I fear they would be many
> specific ones.

Have you seen the results of the test-rebuild performed with the
changed defaults?

I have put together a page with related links and information where
you can find the rebuild results, too:

 https://wiki.debian.org/Hardening/PIEByDefaultTransition

Cheers,
Balint



Re: Enabling PIE by default for Stretch

2016-10-10 Thread Maximiliano Curia

¡Hola Niels!

El 2016-10-10 a las 05:44 +, Niels Thykier escribió:

Niels Thykier:
As brought up on the meeting last night, I think we should try to go for 
PIE by default in Stretch on all release architectures! 
 * It is a substantial hardening feature 
 * Upstream has vastly reduced the performance penalty for x86 
 * The majority of all porters believe their release architecture is 
   ready for it. 
 * We have sufficient time to solve any issues or revert if it turns out 
   to be too problematic.



[...]



 * Deadline for major concerns:  Fri, 7th of October 2016.


It appears that there were no major concerns.  I will follow up #835148 
and request PIE by default for the following architectures.


* amd64 
* arm64 
* armel 
* armhf 
* i386 
* mips 
* mips64el 
* mipsel 
* ppc64el 
* s390x


Such a change will produce unneeded FTBFS's in libraries using -fPIC (such as 
qt5 and all it's dependencies).


Afaik, -fPIC is stronger than -fPIE, at the same time, -fPIE is incompatible 
with -fPIC and -fPIE makes little sense in shared libraries.


And while a single patch should be trivial, I fear they would be many specific 
ones.


Happy hacking,
--
"If a thing is done wrong often enough, it becomes right" -- Leahy's Law
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature


Re: Enabling PIE by default for Stretch

2016-10-09 Thread Niels Thykier
Niels Thykier:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> [...]
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> [...]
> 
> Thanks,
> ~Niels
> 
> [...]

It appears that there were no major concerns.  I will follow up #835148
and request PIE by default for the following architectures.

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

Should you be a porter for an architecture not listed above and want PIE
by default on your architecture, please follow up on #835148 as well (or
a file a new wishlist bug if #835148 is closed when you do it)

NB: The omission of powerpc was intentional as there were no porters
supporting it during the roll-call.

Thanks,
~Niels





Re: Architecture qualification meeting, scheduling

2016-10-08 Thread Niels Thykier
Adrian Bunk:
> [ fullquote adding -ports, for people not following -release or -devel ]
> 
> [...]
> 
> Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
> information available to you, and the "candidate" line how a decision
> would look like based on the current information?
> 
> cu
> Adrian
> 

It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).

If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)

Thanks,
~Niels




Re: Architecture qualification meeting, scheduling

2016-10-08 Thread Adrian Bunk
[ fullquote adding -ports, for people not following -release or -devel ]

On Fri, Oct 07, 2016 at 06:35:07PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> I am arranging the final architecture qualification meeting for Stretch.
> This is primarily of interest to the release team, but I will also take
> input from porters.
> 
> As the schedule is currently wide open, please express your availability in
> the linked Doodle poll. There are 56 slots available, mostly in the European
> evening but a handful are daytime coinciding with the Cambridge
> mini-Debconf.
> 
> Porters, please note your architecture in your response ("name (arch)").
> 
> About the format of the meeting:
> Much like the Jessie meeting, it will be held via IRC in
> oftc.net/#debian-release and will be primarily a discussion amongst the
> release team. We will evaluate each port on the most up-to-date information
> available to us, and determine if it will be a release architecture for
> Stretch. We may ask for clarification from porters who are present if there
> are points at issue, but we ask that you are read-only otherwise.
> 
> http://doodle.com/poll/362qvb89cvu43d4z

Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
information available to you, and the "candidate" line how a decision
would look like based on the current information?

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Re: Porter roll call for Debian Stretch

2016-10-01 Thread Ben Hutchings
On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote:
> On 10/01/2016 02:17 PM, Ben Hutchings wrote:
> > 
> > > 
> > > This isn't the case for PowerPC32 where upstream development is still very
> > > active because it's part of the PowerPC kernel which is maintained by
> > > IBM.
> > 
> > This is not at all true.  My experience is that IBM doesn't even build-
> > test 32-bit configurations, as evidenced by several stable updates
> > causing FTBFS in Debian.
> 
> They care enough that they are fixing bugs. Just recently, a bug in the
> PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only.

$ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc

finds me fewer than ten commits per year.

> > 
> > > 
> > > As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> > > support, so even SPARC is getting back into shape which is why I hope
> > > we can add sparc64 as an official port soon.
> > [...]
> > 
> > Oracle cares about Solaris on SPARC, not Linux on SPARC.
> 
> Well, then you know more than the people at Oracle that I am talking to.
[... much evidence of Oracle supporting Linux on SPARC ...]

OK, I accept this has changed, but I'm quite surprised - Oracle is
ruthlessly commercial, and I'm mystified as to who they expect to buy
it.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.

signature.asc
Description: This is a digitally signed message part


Re: Porter roll call for Debian Stretch

2016-10-01 Thread Ben Hutchings
On Fri, 2016-09-30 at 22:34 +0200, John Paul Adrian Glaubitz wrote:
> On 09/30/2016 09:04 PM, Niels Thykier wrote:
> > 
> > As for "porter qualification"
> > =
> > 
> > We got burned during the Jessie release, where a person answered the
> > roll call for sparc and we kept sparc as a release architecture for
> > Jessie.  However, we ended up with a completely broken and unbootable
> > sparc kernel.
> 
> To be fair, this happened because the upstream kernel development for
> SPARC came to an almost complete stop. There was basically only David
> Miller working on the port which turned out not to be enough.
> 
> This isn't the case for PowerPC32 where upstream development is still very
> active because it's part of the PowerPC kernel which is maintained by
> IBM.

This is not at all true.  My experience is that IBM doesn't even build-
test 32-bit configurations, as evidenced by several stable updates
causing FTBFS in Debian.

> PowerPC32 is also still quite popular which is why it still sees
> quite some testing in the wild. There are still new PowerPC32 designs
> based on embedded CPUs (FreeScale and the like).

Which are very different from the Power Macs and similar platforms that
most Debian powerpc users care about.

> As for SPARC, Oracle is actually now heavily investing in Linux SPARC
> support, so even SPARC is getting back into shape which is why I hope
> we can add sparc64 as an official port soon.
[...]

Oracle cares about Solaris on SPARC, not Linux on SPARC.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part


Re: Porter roll call for Debian Stretch

2016-10-01 Thread Ben Hutchings
On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
[...]
> > I have not heard from the ppc64el porters, but I suspect ppc64 will
> > not be a release arch. So you need to take into consideration that for
> > powerpc to remain a release arch, one need minimal working ppc64 port.
> > Could we solve the situation of ppc64 for Stretch, could it be moved
> > to official release arch ?
> 
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
[...]

This is only the case because ppc64 has a lower level of support
(unofficial port) than powerpc (release architecture).  The 64-bit
kernel package should be dropped once powerpc is at the same or lower
level of support than ppc64 - just as we've done for i386, s390 and
sparc.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part


Re: Porter roll call for Debian Stretch

2016-10-01 Thread Mathieu Malaterre
On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski  wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>>  wrote:
>> [...]
>> > On the other hand, some packages dropped support for PowerPC32 like Mono
>> > but this isn't a concern for most users, I would say.
>> [...]
>>
>> However I need to mention that the specific ppc/mono issue is in fact
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> short version is that this issue only happen because we build the
>> ppc32 mono version on a ppc64 kernel, I know that since I did debug
>> this issue.
>
> Which, if I read the bug correctly, is a yet another case of a bogus
> build system looking at characteristics of the machine it's compiled on
> rather than baseline of the arch.

Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.

> And, per your own work, it's +patch +fixed-upstream.

Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.

>> I have not heard from the ppc64el porters, but I suspect ppc64 will
>> not be a release arch. So you need to take into consideration that for
>> powerpc to remain a release arch, one need minimal working ppc64 port.
>> Could we solve the situation of ppc64 for Stretch, could it be moved
>> to official release arch ?
>
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
>
> powerpc has:
> linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
> i386 has:
> linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
> linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
> linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
> protection
> linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
> linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
>
> Note the joke: "for modern PCs".  Unless you do embedded it takes some
> serious dumpster diving to find a machine not better served by an -amd64
> kernel (and thus multiarch).  The i386 architecture is not self-contained,
> powerpc is.
>
> Thus, there is no need for ppc64 (userland), as long as powerpc has the
> toolchain to build 64-bit kernels.  And that's a primary target for gcc
> upstream.

Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.



Re: Porter roll call for Debian Stretch

2016-09-30 Thread Adam Borowski
On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>  wrote:
> [...]
> > On the other hand, some packages dropped support for PowerPC32 like Mono
> > but this isn't a concern for most users, I would say.
> [...]
> 
> However I need to mention that the specific ppc/mono issue is in fact
> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
> short version is that this issue only happen because we build the
> ppc32 mono version on a ppc64 kernel, I know that since I did debug
> this issue.

Which, if I read the bug correctly, is a yet another case of a bogus
build system looking at characteristics of the machine it's compiled on
rather than baseline of the arch.

And, per your own work, it's +patch +fixed-upstream.

> I have not heard from the ppc64el porters, but I suspect ppc64 will
> not be a release arch. So you need to take into consideration that for
> powerpc to remain a release arch, one need minimal working ppc64 port.
> Could we solve the situation of ppc64 for Stretch, could it be moved
> to official release arch ?

What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
kernels so users don't need multiarch:

powerpc has:
linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC (signed)
linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
(signed)
linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
i386 has:
linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
protection
linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)

Note the joke: "for modern PCs".  Unless you do embedded it takes some
serious dumpster diving to find a machine not better served by an -amd64
kernel (and thus multiarch).  The i386 architecture is not self-contained,
powerpc is.

Thus, there is no need for ppc64 (userland), as long as powerpc has the
toolchain to build 64-bit kernels.  And that's a primary target for gcc
upstream.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.



Re: Porter roll call for Debian Stretch

2016-09-30 Thread Milan Kupcevic
On 09/20/2016 05:46 PM, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
> 


Thank you Adrian for stepping up. You will have my support in this
endeavor for the Stretch release.

Milan




signature.asc
Description: OpenPGP digital signature


Re: Porter roll call for Debian Stretch

2016-09-30 Thread Mathieu Malaterre
Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.

I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?

-M



Re: Porter roll call for Debian Stretch

2016-09-30 Thread John Paul Adrian Glaubitz
On 09/30/2016 09:04 PM, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

To be fair, this happened because the upstream kernel development for
SPARC came to an almost complete stop. There was basically only David
Miller working on the port which turned out not to be enough.

This isn't the case for PowerPC32 where upstream development is still very
active because it's part of the PowerPC kernel which is maintained by
IBM. PowerPC32 is also still quite popular which is why it still sees
quite some testing in the wild. There are still new PowerPC32 designs
based on embedded CPUs (FreeScale and the like).

As for SPARC, Oracle is actually now heavily investing in Linux SPARC
support, so even SPARC is getting back into shape which is why I hope
we can add sparc64 as an official port soon.

>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.

Well, mistakes happen and while I think it's good and important to learn
from mistakes, we should not dramatize such issues. We have had worse
issues like the OpenSSL entropy bug, for example, and we still managed
to cope with the fallout in a very professional manner.

> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).

I don't think there is any concern regarding the powerpc port in this
regard. wanna-build shows almost 11800 packages that are up-to-date
which is a good indicator that the port is in good shape, both regarding
the toolchain and various source packages which need architecture-specific
adaptations like LibreOffice or JavaScript packages.

On the other hand, some packages dropped support for PowerPC32 like Mono
but this isn't a concern for most users, I would say.

> If I am to support powerpc as a realease architecture for Stretch, I
> need to know that there are *active* porters behind it committed to
> keeping it in the working.  People who would definitely catch such
> issues long before the release.  People who file bugs / submit patches etc.

I agree and I'm actually doing that all the time. I always run unstable
on my machines and constantly check wanna-build for build issues and
report them upstream whenever they occur. I have helped dozens of such
issues on "sh4" and "sparc64", for example.

> If you need inspiration: Have a look at the [automatic testing of
> ppc64el images].  Or the [arm64 machines on ci.debian.net] with
> comparable results to amd64.  This is the sort of thing that inspires
> confidence in the ports for me and I think we should have vastly more of.

I agree that would be nice to have. However, to be fair, we don't have
that type of testing for all release architectures and to my current
knowledge, automated testing of installation images is not a criteria
for an architecture to maintain release status.

My main argument for why we should keep the powerpc port is its
popularity. If we look at the numbers from popcon [1], powerpc
is still the fourth-most-popular port and I think we would disappoint
many users if we were to drop the port for Stretch. Note that while
ports like "arm64" or "ppc64el" receive lots of support, especially
from companies, they still haven't reached the same popularity as the
powerpc port for example. Heck, there are even more users for "hppa"
and "sparc64" which both are just unofficial ports architectures.

Thanks,
Adrian

> [1] http://popcon.debian.org/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Porter roll call for Debian Stretch

2016-09-30 Thread Niels Thykier
Niels Thykier:
> [...]
> 
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.
> 
>   That was an embarrassment to the Debian stability and quality
>   reputation that I never - ever - want to repeat.
> 
> (For avoidance of doubt: I want to ensure that release architectures
> "just work(tm)" and I have no desire to blame that volunteer).
> 
> 
> [...]
> 

I have been reminded of my inaccurate memory.  The broken sparc kernel
was released in Wheezy (and discovered during Jessie).  The roll call
for Jessie happened shortly after Wheezy release but before DSA
discovered the broken kernel.

Nonetheless, the core argument still stands.

Thanks,
~Niels




Re: Porter roll call for Debian Stretch

2016-09-30 Thread Adam D. Barratt
On Fri, 2016-09-30 at 19:04 +, Niels Thykier wrote:
> As for "porter qualification"
> =
> 
> We got burned during the Jessie release, where a person answered the
> roll call for sparc and we kept sparc as a release architecture for
> Jessie.  However, we ended up with a completely broken and unbootable
> sparc kernel.

fwiw, you mean wheezy.

Regards,

Adam



Re: Porter roll call for Debian Stretch

2016-09-30 Thread Niels Thykier
John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch.  It may or may not be moved to ports
>> (assuming someone is willing to support it there).
> 
> So, I take this as a "no" for the offer from me and Christoph Biedel to take
> over the powerpc port for Stretch?
> 
> [...]
> 
> Thanks,
> Adrian
> 

My statement above was made based on the assumption stated in the first
line of Mathieu's mail, which was "Assume there are no powerpc porters
for Stretch".

As for "porter qualification"
=

We got burned during the Jessie release, where a person answered the
roll call for sparc and we kept sparc as a release architecture for
Jessie.  However, we ended up with a completely broken and unbootable
sparc kernel.

  That was an embarrassment to the Debian stability and quality
  reputation that I never - ever - want to repeat.

(For avoidance of doubt: I want to ensure that release architectures
"just work(tm)" and I have no desire to blame that volunteer).


If I am to support powerpc as a realease architecture for Stretch, I
need to know that there are *active* porters behind it committed to
keeping it in the working.  People who would definitely catch such
issues long before the release.  People who file bugs / submit patches etc.


If you need inspiration: Have a look at the [automatic testing of
ppc64el images].  Or the [arm64 machines on ci.debian.net] with
comparable results to amd64.  This is the sort of thing that inspires
confidence in the ports for me and I think we should have vastly more of.


Thanks,
~Niels

[automatic testing of ppc64el images]:
 https://lists.debian.org/debian-powerpc/2016/06/msg2.html

[arm64 machines on ci.debian.net]:
 https://ci.debian.net/status/





Re: Porter roll call for Debian Stretch

2016-09-30 Thread Adam Borowski
On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote:
> [Let's assume that we can't find a powerpc porter in time for Stretch.]

Two potential porters stepped up, who might or might not be accepted.

> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?

Removal from the main archive isn't automatic, and assuming no serious
kernel or toolchain breakage, I guess there's no reason for such removal
to be hasty.

On the other hand, place in -ports (aka second-class architectures) isn't
automatic either, and relies on someone doing the work.

> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?

Security support and stable release.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.



Re: Enabling PIE by default for Stretch

2016-09-30 Thread Matthias Klose
[CCing porters, please also leave feedback in #835148 for non-release 
architectures]

On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> As agreed on during the [meeting], if there are no major concerns to
> this proposal in general within a week, I shall file a bug against GCC
> requesting PIE by default on all release architectures (with backing
> porters).

please re-use #835148

>   If there are only major concerns with individual architectures, I will
> simply exclude said architectures in the "PIE by default" request.
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> Fall-out
> 
> 
> There will be some possible fall-out from this change:
> 
>  * There will be some FTBFS caused by some packages needing a rebuild
>before reverse dependencies can enable PIE.  These are a subset of
>the bugs filed in the [pie+bindnow] build tests.
> 
>  * Some packages may not be ready for PIE.  These will have to disable
>it per package.  A notable case being ghc (#712228), where we can
>reuse the patch from Ubuntu to work around the issue.
> 
>  * A possible issue from Matthias was that no one has done a large scale
>"PIE by default" on "arm* mips*".
> 
>  * There was concern about whether the 32bit arm architectures would be
>notably affected by the PIE slow down (like x86 used to be).
>It is not measured, but two arm porters did mention a possible
>slowdown
> 
>  * It was questioned whether it made sense to invest time and effort in
>enabling PIE for architectures which would not be included in Buster
>(armel?). Personally, I do not see an issue, if the porters are
>ready to put in the effort required.
> 
> Thanks,
> ~Niels
> 
> [meeting]:
> http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html
> 
> [pie+bindnow]:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu;dist=unstable
> 
> 
> 
> 



Re: Porter roll call for Debian Stretch

2016-09-30 Thread John Paul Adrian Glaubitz
On 09/30/2016 06:08 PM, Niels Thykier wrote:
> I strongly /suspect/ that "no porters" for powerpc will imply the
> removal of powerpc for Stretch.  It may or may not be moved to ports
> (assuming someone is willing to support it there).

So, I take this as a "no" for the offer from me and Christoph Biedel to take
over the powerpc port for Stretch?

I have quite some experience with working on ports and unlike what Matthias 
claimed,
I'm not just maintaining a few buildds but also getting architecture-specific 
bugs
fixed and so on.

Is there any specific qualification I am missing?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Porter roll call for Debian Stretch

2016-09-30 Thread Christian Zigotzky
You have a porter for PowerPC. See email from Adrian. ;-)

-- Christian

Sent from my iPhone

> On 30 Sep 2016, at 10:03, Mathieu Malaterre  wrote:
> 
> Hi all,
> 
>> On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
>>> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
 On 09/20/2016 11:16 PM, Niels Thykier wrote:
   - powerpc: No porter (RM blocker)
>>> 
>>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>>> maintaining powerpcspe which is very similar to powerpc.
>> 
>> No, you are not maintaining powerpcspe as a release architecture, and that's
>> something different than building packages for some of the ports 
>> architectures.
>> If you can get powerpcspe accepted as a release architecture, then maybe you
>> gain some credibility to maintain another release architecture ;)
> 
> [Let's assume that we can't find a powerpc porter in time for Stretch.]
> 
> 1. Will `powperpc` automatically be downgraded to simple port ? Or is
> this also not automated and the port may simply be removed (eg. sparc)
> ?
> 2. Apart from loosing the automatic debian-installer stuff, what else
> are we going to loose in that scenario ?
> 
> Thanks much for pointers !
> 
> -M
> 



Servicio de Logistica desde los Principales Puertos del Pais.

2016-09-27 Thread Logisven - Logística en 4 principales puertos y Alquiler de Grúas
 

estimados srs. 


 

queremos presentarle nuestra organización y tener la posibilidad de 
convertirnos en proveedores de logística de su empresa.

nuestros principales casos de exito son:

  coordinación logística a nivel nacional e internacional
  [1] miss venezuela - transporte de caracas a
  maracaibo

  coordinación de carga suelta extradimensionada en gandolas lowboy
  [2] bzs - transporte de 150 equipos maquinaria agricola y construcción

  [3] ingenieria y - transformadores transporte e izamiento

  [4] exportación a en lowboy a colombia

contenedores y carga suelta desde los 4 principales puertos.
[5] caso de éxito - sidor transporte de planta siderurgica guanta-puerto ordaz
[6] transporte de azucar desde la guaira a barcelona
[7] odebrecht - transporte de metrocable

el siguiente es un vínculo por el cual puede proceder a descargar la 
presentación de nuestra empresa
  [8] logisven-presentacion-comercial.pdf
esperando su pronta respuesta y así crear un vínculo comercial de largo plazo 
entre nuestras organizaciones.

un cordial saludo,

luis gonzalez
presidente

  [9] merca...@logisven.com
  [10] www.logisven.com 

logisven - coordinación logística y gruas
caracas, maracaibo, barquisimeto, san cristóbal, pto. cabello, 
valencia, maracay, valles del tuy, la guaira, pto. la cruz,
guanta, pto. ordaz , san antonio, paraguachón

nuestros servicios
 

 [11]

 

 

 

 
dear  ,

¿ quienes somos?

somos una empresa con gran experiencia y trayectoria en logística en venezuela

contáctenos
www.logisven.com
     merca...@logisven.com

vinculos
 [12] misión y visión

  [13] nuestro modelo de negocio

  [14] cobertura geográfica

 

  [15] solicitud


 References:

1. u=67c8aac
2. u=67c8f72
3. u=67c8f65
4. u=67c8f63
5. u=67c889b
6. u=67c890c
7. u=67c8f8b
8. u=67c9039
9. mailto:merca...@logisven.com
10. u=67c905a
11. u=67c85c3
12. u=67c907f
13. u=67c907f
14. u=67c907f
15. u=67c907f


Re: Porter roll call for Debian Stretch

2016-09-25 Thread Christoph Biedl
John Paul Adrian Glaubitz wrote...

> On 09/20/2016 11:16 PM, Niels Thykier wrote:
> >- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

For somewhat personal reasons I'm interested in keeping powerpc in
stretch as well. I certainly cannot take the entire role as a porter,
especially since I don't know what amount of work this implies. But I
am willing to help.

There are two powerpc boxes in my collection, used regulary. One runs
on stable, the other on testing. I haven't done d-i tests but
certainly could do.

Christoph



signature.asc
Description: Digital signature


Re: Porter roll call for Debian Stretch

2016-09-23 Thread John Paul Adrian Glaubitz
On 09/23/2016 03:54 PM, Matthias Klose wrote:
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

So, what are the criteria to be knighted to become a maintainer of powerpc?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: Porter roll call for Debian Stretch

2016-09-23 Thread Matthias Klose
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

No, you are not maintaining powerpcspe as a release architecture, and that's
something different than building packages for some of the ports architectures.
If you can get powerpcspe accepted as a release architecture, then maybe you
gain some credibility to maintain another release architecture ;)

Matthias



Re: Porter roll call for Debian Stretch

2016-09-21 Thread Riku Voipio
On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf



Re: Porter roll call for Debian Stretch

2016-09-20 Thread John Paul Adrian Glaubitz
On 09/20/2016 11:16 PM, Niels Thykier wrote:
>- powerpc: No porter (RM blocker)

I'd be happy to pick up powerpc to keep it for Stretch. I'm already
maintaining powerpcspe which is very similar to powerpc.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



signature.asc
Description: OpenPGP digital signature


Re: Porter roll call for Debian Stretch

2016-09-20 Thread Niels Thykier
ni...@thykier.net:
> Hi,
> 
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  [...]
> 

Thanks to all that replied to the roll call.

We got replies from all architectures except amd64 (Waived), i386
(Waived) and powerpc (problematic).  For the ports that replied, all had
at least 2 or more porters.
  We also got a parallel update from Matthias Klose on the toolchain
state[1].  Based on these we have updated the current state of the
architecture qualification for Stretch[2].

 * Please check that your name is listed as a porter on [2] (see [3]
   for how).  If I missed you, please do not hesitate to let me know.

 * For powerpc, mips and mipsel: Please note that we have added a
   (potentially) blocking issues for your architecture.
   - powerpc: No porter (RM blocker)
   - mips+mipsel: #834147 (RM concern, possibly blocker)


As for the piggy backed question about PIE by default:

 * arm64: 2 OK, 1 did not mention it
 * armel: 3 OK, 1 OK if tested first, 1 was neutral and 1 did not
   mention it
 * armhf: 4 OK, 1 OK if tested first, 1 was neutral and 2 did not
   mention it
 * mips+mipsel+mips64el: 3 OK, 1 OK later, 4 did not mention it.
 * ppc64el: 3 OK, 1 recommended further testing/research
 * s390x: 2 OK

Over all, most people (who answered it) was positive towards the switch.
 Based on this, I suspect that if we make PIE default in Stretch, then
we will do it for all architectures.  That said, you will be notified if
that default changes for Stretch.

Thanks,
~Niels

[1] https://lists.debian.org/debian-release/2016/09/msg00263.html

[2] https://release.debian.org/stretch/arch_qualify.html

[3] Hover your mouse over the number of porters for your architecture
or download the underlying data file from:
  https://release.debian.org/stretch/arch_spec.yaml




signature.asc
Description: OpenPGP digital signature


Re: The (uncalled for) toolchain maintainers roll call for stretch

2016-09-15 Thread Helge Deller
Hi Matthias,

On 10.09.2016 00:48, Matthias Klose wrote:
> While the Debian Release team has some citation about the quality of the
> toolchain on their status page, it is not one of the release criteria 
> documented
> by the release team.  I'd like to document the status how I do understand it 
> for
> some of the toolchains available in Debian.

> Java/OpenJDK
> 
> 
> For the stretch release openjdk-8 will be fine as the default java
> implementation.  For buster, gcj (to be removed in GCC 7) won't be available
> anymore, and we'll end up with architectures without a java implementation.  
> At
> the same time I'd like to consider to stop providing OpenJDK zero builds,
> leaving powerpc and mips* without a java implementation as well (currently not
> building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
> underway.

Can you explain the reason why you consider stopping OpenJDK zero builds?

I'm asking, because on hppa we currently use gcj and we don't have any OpenJDK 
port yet.
My hope was to fix at some point in future the old existing OpenJDK zero port 
patches to get some newer
JDK even if it's slower. With your intention to stop zero builds, we probably 
won't have any
JDK at all...

Thanks,
Helge



Re: The (uncalled for) toolchain maintainers roll call for stretch

2016-09-10 Thread John Paul Adrian Glaubitz
On 09/10/2016 12:48 AM, Matthias Klose wrote:
> Uncovered by the upstream primary and secondary platforms are the mips*
> architectures and powerpc.  For the uncovered archs I would expect somehow 
> more
> and pro-active Debian maintenance, however I fail to see this happen.
> 
>  - see the history of ftbfs on the buildd page of the gcc-snapshot package
>  - see the status of the gcc-6 package for the pre-release uploads
>  - see the number of RC issues for binutils which came up with 2.27,
>some still open.
>  - Toolchain packages are not watched by porters, and I can't track
>every regression myself, however this is not done well by porters.
> 
> On the recent Porter's call I didn't see any toolchain support for the powerpc
> architecture.

I would actually be happy to take over the powerpc port as its official porter.
I'm already taking care of powerpcspe, so I think it would be a perfect fit.

Let me know what needs to be done to make this happen! I don't want to see
powerpc go too soon.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: The (uncalled for) toolchain maintainers roll call for stretch

2016-09-10 Thread Paul Gevers
Hi,

On 10-09-16 00:48, Matthias Klose wrote:
>  - fpc not available on powerpc anymore (may have changed recently)

For whatever it is worth, this was finally fixed this week. It is
missing on mips*, ppc64el and s390x though, while at least some form of
MIPS is supported upstream.

Paul



signature.asc
Description: OpenPGP digital signature


The (uncalled for) toolchain maintainers roll call for stretch

2016-09-09 Thread Matthias Klose
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team.  I'd like to document the status how I do understand it for
some of the toolchains available in Debian.

I appreciate that the release criteria are somehow "reset" for the stretch
release, and not copied from previous release decisions.

GNU toolchain (GCC / binutils)
--

GCC upstream has the notation of primary and secondary platforms, with the
commitment to fix issues on these platforms [1], [2].  Debian architectures
within the set of these platforms are:

 - aarch64-none-linux-gnu (starting with GCC 7)
 - arm-linux-gnueabi
 - i686-pc-linux-gnu
 - powerpc64-unknown-linux-gnu
 - x86_64-unknown-linux-gnu
 - s390x-linux-gnu

Release architectures missing in the primary and secondary platforms:

 - armhf
 - mips*
 - powerpc
 - ppc64el

As you see with arm64, new architectures become primary or secondary platforms
only after a while, so that may explain the absence of
powerpc64le-unknown-linux-gnu.

The arm-linux-gnueabi is not that well defined, so it may include the hard float
variant as well.  However Debian default to armv4t, while the default
configuration for upstream is armv5.  However with the selected defaults
Debian's libstdc++::future module is not complete and causes build failures on
this architecture (same for sparc).

Uncovered by the upstream primary and secondary platforms are the mips*
architectures and powerpc.  For the uncovered archs I would expect somehow more
and pro-active Debian maintenance, however I fail to see this happen.

 - see the history of ftbfs on the buildd page of the gcc-snapshot package
 - see the status of the gcc-6 package for the pre-release uploads
 - see the number of RC issues for binutils which came up with 2.27,
   some still open.
 - Toolchain packages are not watched by porters, and I can't track
   every regression myself, however this is not done well by porters.

On the recent Porter's call I didn't see any toolchain support for the powerpc
architecture.  For the mips* architectures we apparently have five or more
active toolchain maintainers.  I very much doubt that view.  From my point of
view these architecture would be perfect candidates for partial architectures,
and until then should be removed from the set of the release architectures. For
mips* that shouldn't be no news; please see my comments regarding both the
toolchain and buildd status since at least DebConf 12 (release meetings during
DebConfs).

Java/OpenJDK


For the stretch release openjdk-8 will be fine as the default java
implementation.  For buster, gcj (to be removed in GCC 7) won't be available
anymore, and we'll end up with architectures without a java implementation.  At
the same time I'd like to consider to stop providing OpenJDK zero builds,
leaving powerpc and mips* without a java implementation as well (currently not
building for openjdk-9).  armhf (not armel) and s390x have Hotspot ports 
underway.

Other toolchains


 - clang/llvm not available on armel since 3.8.
 - fpc not available on powerpc anymore (may have changed recently)
 - mono not available more on powerpc


Being demoted as a release architecture certainly is not a nice thing, and
looking at past demotions, these were not done very coordinated, not allowing
builds in the ports archive for some months.  It would be good to find some
middle-ground such that a port's demotion isn't a final thing, and it has a
chance to become a release architecture again, maybe even as a partial
architecture if we can define the meaning of such a thing.

Matthias

[1] https://gcc.gnu.org/gcc-6/criteria.html
[2] https://gcc.gnu.org/gcc-7/criteria.html



Transporte de Carga - Alquiler de Maquinaria de Construcción y Grúas

2016-09-08 Thread Logisven - Coordinación Logística y Alquiler de Grúas
 

estimados srs. 


 

queremos presentarle nuestra organización y tener la posibilidad de 
convertirnos en proveedores de logística de su empresa.

nuestros principales servicios son:

  coordinación logística a nivel nacional e internacional
  coordinación de carga suelta en gandolas
  contenedores desde los 4 principales puertos.
  alquiler de grúas telescópicas.

el siguiente es un vínculo por el cual puede proceder a descargar la 
presentación de nuestra empresa
  [1] logisven-presentacion-comercial.pdf
esperando su pronta respuesta y así crear un vínculo comercial de largo plazo 
entre nuestras organizaciones.

un cordial saludo,

luis gonzalez
presidente

  [2] merca...@logisven.com
  [3] www.logisven.com 

logisven - coordinación logística y gruas
caracas, maracaibo, barquisimeto, san cristóbal, pto. cabello, 
valencia, maracay, valles del tuy, la guaira, pto. la cruz,
guanta, pto. ordaz , san antonio, paraguachón

nuestros servicios
 

 [4]

 

 

 

 
dear  ,

lorem ipsum dolor sit amet consectetuer nulla urna porttitor eget aliquam vel 
placerat feugiat orci. phasellus tellus pede pulvinar et scelerisque a tempor a 
velit. morbi feugiat. etiam ut elit ac metus facilisis fermentum.

¿ quienes somos?

somos una empresa con gran experiencia y trayectoria en logística en venezuela

contáctenos
www.logisven.com
     merca...@logisven.com

vinculos
 [5] misión y visión

  [6] nuestro modelo de negocio

  [7] cobertura geográfica

 

  [8] solicitud


 References:

1. u=64c2f76
2. mailto:merca...@logisven.com
3. u=64c2f77
4. u=64c2f78
5. u=64c2f79
6. u=64c2f7a
7. u=64c2f7b
8. u=64c2f7c


Re: Porter roll call for Debian Stretch

2016-09-04 Thread Roger Shimizu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 17 Aug 2016 22:05:06 +0200
ni...@thykier.net wrote:

> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 

Hi,

I am an active porter for the following architectures and I intend
to continue this for the lifetime of the Stretch release (est. end
of 2020):

For armel, I
 - submit device-tree patch to upstream (linux kernel), and backport to debian 
kernel to get more devices supported
 - support new device for d-i and flash-kernel package
 - test most packages on this architecture
 - run Debian stable / testing / unstable system on port that I use regularly
 - triage arch-specific bugs
 - fix arch-related bugs
 - triage d-i bugs
 - test d-i regularly
 - fix d-i bugs/issues

I am a DM.

Altough I enabled -fPIE/-pie for most of my maintaining packages, I'm not sure 
/ I don't have enough knowledge whether it's able to be applied to all packages.
Since all other ARM porters seem agree on this, I believe it definitely 
deserves a try to enable this hardening on stretch.

Cheers,
- -- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXzEFiAAoJEKR4aw2nAzSoAekP/j4eNf0jKvmArPlPbhA7XkBk
/5u9Un4qOHBNcSMAU5YVLHkpnT1CX/C08W+/ctGbB9AnnRwyn8X0uailjedZ13jK
oZYW/kUSwWiPmOkRTeNgFepzuKL+TNsAGgjHOY4ZbzYKC+h9C0UNWwyA77L3GUep
3HA9eTrtxMAAvJPNN4AhOjMeCI3qXIZ+wLKjhT+u/OUETWly8MolBw8PUjjwW6yy
Va7ciRMQf8KL149+Pa/tYFaENoAOV6//3M2QkJyaGbfxJp3xiFFcrlw+kw6J4RyH
vNIewz78nZwN88Y7JWa2EdBVcJr0897REXpDPXK/OpzlWw0R0xqB86jtmHfc+rQJ
IiNGt5Uc4Y3mD04O6AEDDJFJnEQ/QLi8OR8/TuxHiBJ6JTv0m67KsJVgdFqeRnlz
wJqcIQAzTF1iixVXjreVqW6P/+pGNHDbh9APfUz+UV97sZ4tD2BV1K1Rgk7cPDCn
zcpVhkQRy5PzLmK315vb8h9juFDDS/18yzmXwGMnmIhv4+8GBJIQLm5gvk9NuEbw
V/hBC42+fqX6RzGCoV3M8V+A6aLSpG/BcIAQOx8ewVfzMHIFSJmYParCHKXdiX+z
WB8UBt2xCHuzg98jxU80UwR492X9WvKeb6xA8dKqOW22XzsLxaQTe+SLSaGQ7er2
cpuhCpYFDKj/TL6UE2f9
=Vckg
-END PGP SIGNATURE-



Re: Porter roll call for Debian Stretch

2016-08-21 Thread Guillem Jover
Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem



<    1   2   3   4   5   6   7   8   9   10   >