[Ticket ID: 104966] Accepted docker.io 1.3.3~dfsg1-2 (source amd64 all) into unstable
Tianon Gravi Tianon Gravi, Recebemos seu ticket em 03/01/2015 e o mesmo será respondido o mais rápido possível. ID Ticket: 104966 Assunto: Accepted docker.io 1.3.3~dfsg1-2 (source amd64 all) into unstable Prioridade: Média Status: Aberto Departamento: Suporte Geral IMPORTANTE: Não responda este e-mail pois poderá atrasar o tempo de resposta do mesmo. Para acompanhar o andamento das respostas deste ticket: Clique Aqui
Bug#774458: ITP: mgrs -- Utility for converting between WGS84 lat/lng and MGRS coordinates
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: mgrs Version : 0.0~20131209-80d5465 Upstream Author : proj4js Developers * URL : https://github.com/proj4js/mgrs * License : Expat Programming Lang: Javascript Description : Utility for converting between WGS84 lat/lng and MGRS coordinates mgrs is a utility for converting between WGS84 lat/lng and MGRS coordinates, spunoff from proj4js. It has 3 methods: * forward, takes an array of [lon,lat] and optional accuracy and returns an mgrs string * inverse, takes an mgrs string and returns a bbox * toPoint, takes an mgrs string, returns an array of '[lon,lat]' This package contains the mgrs utility for Node.js. Node.js is an event-based server-side JavaScript engine. The package is a dependency of proj4js (#774112) and will be maintained in the Debian GIS team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102232801.10450.1763.report...@osiris.linuxminded.xs4all.nl
Re: dpkg packaging problems
On Fri, Jan 02, 2015 at 06:16:17PM +0100, Enrico Weigelt, metux IT consult wrote: > On 02.01.2015 17:08, Martin Pitt wrote: > > Yes, man dh_fixperms. Shared libraries don't need to and should not be > > executable. > > Oh, wasn't aware of that. Just used to that as gcc sets that flag. > Is it a bug in gcc, or are there platforms where +x is required ? https://unix.stackexchange.com/questions/40587/why-are-shared-libraries-executable reports it as being necessary on HP-UX. It's indeed not needed on Linux except for the odd special case, though. -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102181618.ga16...@riva.ucam.org
Re: dpkg packaging problems
On Fri, 2015-01-02 at 18:16 +0100, Enrico Weigelt, metux IT consult wrote: > On 02.01.2015 17:08, Martin Pitt wrote: > > Hi, > > > Yes, man dh_fixperms. Shared libraries don't need to and should not be > > executable. > > Oh, wasn't aware of that. Just used to that as gcc sets that flag. > Is it a bug in gcc, or are there platforms where +x is required ? ld sets the flag, and I suspect this is because it can't tell the difference between a shared library and a PIE. A shared library may work as a executable anyway, e.g.: $ /lib/i386-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.19-13) stable release version 2.19, by Roland McGrath et al. Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [...] Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Re: dpkg packaging problems
On 02.01.2015 17:08, Martin Pitt wrote: Hi, > Yes, man dh_fixperms. Shared libraries don't need to and should not be > executable. Oh, wasn't aware of that. Just used to that as gcc sets that flag. Is it a bug in gcc, or are there platforms where +x is required ? cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54a6d261.9070...@gr13.net
Re: dpkg packaging problems
Hello Enrico, Enrico Weigelt, metux IT consult [2015-01-02 16:52 +0100]: > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( Yes, man dh_fixperms. Shared libraries don't need to and should not be executable. If you have a corner case where that's desirable, use -X to exclude those from permission fixes. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102160840.gd3...@piware.de
Re: dpkg packaging problems
On Fri, 02 Jan 2015 16:52:10 +0100 "Enrico Weigelt, metux IT consult" wrote: > Hi folks, > > I'm just packaging some library to various deb distros using > pbuilder + git-buildpackage. > > Unfortunately, the .so's loose the +x flag in the package > (while usual 'make install' is okay) - it seems that some of the > dh stuff drops that flag :( This is correct. Why would a .so be executable? $ find /usr/lib/x86_64-linux-gnu/ -type f -executable -name '*.so*' $ $ find /usr/lib/x86_64-linux-gnu/ -type f -executable -name '*.so' $ https://www.debian.org/doc/debian-policy/ch-files.html#s-libraries Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped. A common example are the so-called "plug-ins", internal shared objects that are dynamically loaded by programs using dlopen(3). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp009n6nQZ7x.pgp Description: OpenPGP digital signature
Re: dpkg packaging problems
On 01/02/2015 at 10:52 AM, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > I'm just packaging some library to various deb distros using pbuilder > + git-buildpackage. > > Unfortunately, the .so's loose the +x flag in the package (while > usual 'make install' is okay) - it seems that some of the dh stuff > drops that flag :( Are .so files really supposed to have +x? On my system, the only *.so files under /lib*/ /usr/lib*/ /usr/local/lib*/ which appear to have any executable bit set are ld.so, libpthread, libc, and the many .so files from my locally-built (and not dpkg-installed) copy of Wine. That leads me to suspect that it's intentional that .so files are not marked executable in Debian. According to the Debian Policy Manual section 8.1 [1], "Shared libraries should not be installed executable, since the dynamic linker does not require this and trying to execute a shared library usually results in a core dump.". Also, there appears to be a lintian tag warning against doing this [2], which states that "Shared libraries should be mode 0644.". Is there a particular reason why these library files need to be executable in this particular case? [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime [2] https://lintian.debian.org/tags/shlib-with-executable-bit.html -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
dpkg packaging problems
Hi folks, I'm just packaging some library to various deb distros using pbuilder + git-buildpackage. Unfortunately, the .so's loose the +x flag in the package (while usual 'make install' is okay) - it seems that some of the dh stuff drops that flag :( maybe some of you guys might have an idea ? See: https://github.com/metux/fskit/tree/jessie/master https://github.com/metux/fskit/tree/trusty/master the build process is driven by: https://github.com/metux/packaging cu -- Enrico Weigelt, metux IT consulting +49-151-27565287 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54a6beaa.8060...@gr13.net
Re: motd handling in jessie & beyond
On Fri, Jan 02, 2015 at 04:16:44PM +0200, Faidon Liambotis wrote: > What is your concern with shipping a simple executable shell script? Actually, it's not the executable what does not belong to base-files, it's the *functionality*. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102151137.ga23...@cantor.unex.es
Re: motd handling in jessie & beyond
On Fri, Jan 02, 2015 at 04:16:44PM +0200, Faidon Liambotis wrote: > On Wed, Dec 31, 2014 at 07:08:22PM +0100, Santiago Vila wrote: > > On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote: > > > c) base-files shipping /etc/update-motd.d, plus a script: > > >00-uname: #!/bin/sh\nuname -snrvm\n > > > > Could you please choose another package? debianutils comes to mind. > > Currently, base-files has no binaries at all, and I'd like to keep > > it that way. > > What is your concern with shipping a simple executable shell script? > > base-files was suggested because it's the package that currently ships > our default static motd text. While I don't personally have a > preference on the place that uname call should be (if anywhere!), I do > think that keeping all of Debian's motd default contents -whether a > static blob of text or dynamic scripts- in one place would make the most > sense. AFAIK, base-files has never had any binaries in it, ever. It's called base-*files* for a good reason. I'm happy to keep the default motd if it's useful, but if people insist that the code to handle motd should be in the same package as the default motd, then please take out the default from base-files as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102150542.ga23...@cantor.unex.es
Re: motd handling in jessie & beyond
On Wed, Dec 31, 2014 at 07:08:22PM +0100, Santiago Vila wrote: > On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote: > > c) base-files shipping /etc/update-motd.d, plus a script: > >00-uname: #!/bin/sh\nuname -snrvm\n > > Could you please choose another package? debianutils comes to mind. > Currently, base-files has no binaries at all, and I'd like to keep > it that way. What is your concern with shipping a simple executable shell script? base-files was suggested because it's the package that currently ships our default static motd text. While I don't personally have a preference on the place that uname call should be (if anywhere!), I do think that keeping all of Debian's motd default contents -whether a static blob of text or dynamic scripts- in one place would make the most sense. Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102141636.ga32...@tty.gr
Re: motd handling in jessie & beyond
On Fri, Jan 02, 2015 at 11:56:44AM +0100, Ansgar Burchardt wrote: > as this seems to be only about including the output of `uname' in motd, > how about just *not* including it? I never found it to be particular > helpful anyway... > > If you want to include information about the machine you are connecting > to, then the OS version, amount of RAM, number and speed of processors, > and system architecture are probably more helpful than just the kernel > version the system is running. I hear you -- the OS version alone is far more useful than uname in my opinion. However, I think this is a separate question. This discussion is about the common interface between a number of key packages that: a) makes the behavior consistent between different login methods and init systems (a jessie regression), b) moves that uname call in one config file and one package rather than hardcoding that uname call in 2-4 places (including pam.d configs & init scripts, which while config files, people generally avoid to customize), c) allows customization by the sysadmin and/or other packages. The /etc/update-motd.d mechanism as is shipped in Ubuntu and partially shipped in Debian is excellent for this in my opinion, as it's just arbitrary scripts that can run and print whatever you want them to. For example, Ubuntu's update-notifier ships /etc/update-motd.d stanzas that print the number of package upgrades pending and whether a reboot is required because the kernel has been previously upgraded. Now, what really belongs in our motd and what doesn't is a discussion that is probably worth having, but I'd personally prefer it if we defer it for after we have a common interface that allows us to do those customizations and do them in one place. Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102140954.ga28...@tty.gr
Re: motd handling in jessie & beyond
On 01/02/2015 at 05:56 AM, Ansgar Burchardt wrote: > Hi, > > as this seems to be only about including the output of `uname' in > motd, how about just *not* including it? I never found it to be > particular helpful anyway... > > If you want to include information about the machine you are > connecting to, then the OS version, amount of RAM, number and speed > of processors, and system architecture are probably more helpful than > just the kernel version the system is running. The kernel version isn't the only information in the uname output in question. The uname call which is apparently being used includes the following: '-s' (kernel name, generally "Linux") '-n' (hostname of the system in question) '-r' (kernel release, which is generally just a version number) '-v' (kernel version, which may be a longer string; on my system it includes the version number from '-r', which thus appears twice) '-m' (machine hardware name - on my system it's 'x86_64') I think the hostname is useful information, which I wouldn't want to see omitted; I also think the architecture may be nice to know. The rest of it, while potentially useful information, isn't necessarily the sort of thing that needs to be reported on every login. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: motd handling in jessie & beyond
Hi, as this seems to be only about including the output of `uname' in motd, how about just *not* including it? I never found it to be particular helpful anyway... If you want to include information about the machine you are connecting to, then the OS version, amount of RAM, number and speed of processors, and system architecture are probably more helpful than just the kernel version the system is running. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4plwivn@deep-thought.43-1.org
