Bug#1023397: Unwanted files in the flightgear binary package
Package: flightgear Version: 1:2020.3.16+dfsg-1 Severity: minor Dear Maintainer, The Flightgear binary package includes a couple unwanted files: - /usr/share/icons/hicolor/CMakeLists.txt - /usr/share/applications/org.flightgear.FlightGear.desktop The desktop package is provided by Flighgrear upstream, while Debian also ships /usr/share/applications/flightgear.desktop
[Nix-commits] [NixOS/nixops] d90fb6: Add `--no-build-output` option (#658)
Branch: refs/heads/master Home: https://github.com/NixOS/nixops Commit: d90fb6750af907374ed6c458dfe0d2e05134a32b https://github.com/NixOS/nixops/commit/d90fb6750af907374ed6c458dfe0d2e05134a32b Author: Igor Pashev <pashev.i...@gmail.com> Date: 2017-05-08 (Mon, 08 May 2017) Changed paths: M scripts/nixops Log Message: --- Add `--no-build-output` option (#658) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 7e48ec: Merge nixpkgs.config.perlPackageOverrides
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 7e48ecc0c00086455268960b6bc444efb4320821 https://github.com/NixOS/nixpkgs/commit/7e48ecc0c00086455268960b6bc444efb4320821 Author: Igor Pashev <pashev.i...@gmail.com> Date: 2016-08-24 (Wed, 24 Aug 2016) Changed paths: M nixos/modules/misc/nixpkgs.nix Log Message: --- Merge nixpkgs.config.perlPackageOverrides ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 54aee1: autoreconf may need gettext
Branch: refs/heads/release-14.12 Home: https://github.com/NixOS/nixpkgs Commit: 54aee1152c0fc1464ac35cb50f75cef05b0a39ee https://github.com/NixOS/nixpkgs/commit/54aee1152c0fc1464ac35cb50f75cef05b0a39ee Author: Igor Pashev pashev.i...@gmail.com Date: 2014-12-30 (Tue, 30 Dec 2014) Changed paths: M pkgs/build-support/setup-hooks/autoreconf.sh M pkgs/top-level/all-packages.nix Log Message: --- autoreconf may need gettext E. g. for AC_LIB_PREFIX (cherry picked from commit d57927748a9298780370a66ccb649992cb162646) Commit: 5776334cae9013fd056c3f7002dab06a7bd9e244 https://github.com/NixOS/nixpkgs/commit/5776334cae9013fd056c3f7002dab06a7bd9e244 Author: Igor Pashev pashev.i...@gmail.com Date: 2014-12-30 (Tue, 30 Dec 2014) Changed paths: M pkgs/tools/networking/strongswan/default.nix A pkgs/tools/networking/strongswan/firewall_defaults.patch Log Message: --- Strongswan: use full path to ipsec This fixes issue: ... charon[6135]: 11[CHD] updown: /bin/sh: ipsec: command not found (cherry picked from commit 9bbe674927a307f02d32834c9a39f49c8be476e7) Commit: 9868631cb46926b836318ac7f8cc318b61266191 https://github.com/NixOS/nixpkgs/commit/9868631cb46926b836318ac7f8cc318b61266191 Author: Igor Pashev pashev.i...@gmail.com Date: 2014-12-30 (Tue, 30 Dec 2014) Changed paths: M nixos/modules/services/networking/strongswan.nix Log Message: --- Strongswan: updown script uses ip and iptables utilities (cherry picked from commit 2b91b9b5941d9ef31ab4e0772ffa03c023abd2cc) Commit: 25e22678d2770bb6b6087993909854d769d78316 https://github.com/NixOS/nixpkgs/commit/25e22678d2770bb6b6087993909854d769d78316 Author: Igor Pashev pashev.i...@gmail.com Date: 2014-12-30 (Tue, 30 Dec 2014) Changed paths: M pkgs/tools/networking/strongswan/default.nix A pkgs/tools/networking/strongswan/ext_auth-path.patch A pkgs/tools/networking/strongswan/updown-path.patch Log Message: --- Strongswan: preserve PATH (cherry picked from commit 17d8029150b246d9cd67174120900ea6bdbedda4) Compare: https://github.com/NixOS/nixpkgs/compare/a55eb1a8b9b4...25e22678d277___ nix-commits mailing list nix-commits@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] a8dd23: saga: update from 2.1.2 to 2.1.4 and re-enable bui...
/4f9111e91f180165aa43cc9dafb7f95b79686215 Author: Igor Pashev pashev.i...@gmail.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/tools/networking/strongswan/default.nix Log Message: --- strongSwan needs python for building (Closes #4940) Commit: 4c33004e1f962d44a5f3f1f4efb057f385b3b764 https://github.com/NixOS/nixpkgs/commit/4c33004e1f962d44a5f3f1f4efb057f385b3b764 Author: Igor Pashev pashev.i...@gmail.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/networking/strongswan.nix Log Message: --- Added strongSwan service Commit: d250ca4e317c8d8ca1a0ec5bfe84eb7c828b6ecc https://github.com/NixOS/nixpkgs/commit/d250ca4e317c8d8ca1a0ec5bfe84eb7c828b6ecc Author: Cillian de Róiste cillian.deroi...@gmail.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/applications/graphics/openimageio/default.nix Log Message: --- openimageio: update from 1.4.14 to 1.4.15 Commit: 957eb52f6f4a467910088e8ef3434beca49ce8fc https://github.com/NixOS/nixpkgs/commit/957eb52f6f4a467910088e8ef3434beca49ce8fc Author: Shea Levy s...@shealevy.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/networking/strongswan.nix M pkgs/tools/networking/strongswan/default.nix Log Message: --- Merge branch 'strongswan' of github.com:ip1981/nixpkgs Add strongswan service Commit: dd2dedafa337888bd85b3df6bbcfb26ab7398c56 https://github.com/NixOS/nixpkgs/commit/dd2dedafa337888bd85b3df6bbcfb26ab7398c56 Author: Eelco Dolstra eelco.dols...@logicblox.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M nixos/modules/services/networking/strongswan.nix Log Message: --- Style fixes Commit: 1abc3e01550a4c1119d9284a09fe9c04d43ba53f https://github.com/NixOS/nixpkgs/commit/1abc3e01550a4c1119d9284a09fe9c04d43ba53f Author: Eelco Dolstra eelco.dols...@logicblox.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/applications/networking/browsers/firefox-bin/default.nix M pkgs/applications/networking/mailreaders/thunderbird-bin/default.nix Log Message: --- firefox-bin: Fix meta.license Commit: a4beb6a2b65881849a858ba4ea42bc5763712df2 https://github.com/NixOS/nixpkgs/commit/a4beb6a2b65881849a858ba4ea42bc5763712df2 Author: Ricardo M. Correia rcorr...@wizy.org Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-11/default.nix Log Message: --- flashplayer: Update from 11.2.202.418 - 11.2.202.424 Commit: 60e661074dc88ed43ffe56c8952c6740d5c67601 https://github.com/NixOS/nixpkgs/commit/60e661074dc88ed43ffe56c8952c6740d5c67601 Author: Oliver Charles ol...@ocharles.org.uk Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/development/libraries/haskell/ekg-bosun/default.nix Log Message: --- haskellPackages.ekgBosun: New expression Commit: 880f6a517e0d7c8a41b2adfc4a6bc684819670e7 https://github.com/NixOS/nixpkgs/commit/880f6a517e0d7c8a41b2adfc4a6bc684819670e7 Author: Pascal Wittmann m...@pascal-wittmann.de Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/tools/misc/bmon/default.nix Log Message: --- bmon: update from 3.5 to 3.6 Commit: 10c9196c0f0186ca303d4315267c4b938e07a301 https://github.com/NixOS/nixpkgs/commit/10c9196c0f0186ca303d4315267c4b938e07a301 Author: Pascal Wittmann m...@pascal-wittmann.de Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/tools/misc/parallel/default.nix Log Message: --- parallel: update from 20141022 to 20141122 Commit: c73ce5fa1e0fa1744a3fe349dc0e0f3fc6c58ce8 https://github.com/NixOS/nixpkgs/commit/c73ce5fa1e0fa1744a3fe349dc0e0f3fc6c58ce8 Author: Pascal Wittmann m...@pascal-wittmann.de Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: M pkgs/development/compilers/lessc/default.nix Log Message: --- lessc: add comment that versions 2.x break twitter-bootstrap Commit: 49561b8b650606ecab2ae954cf7b4765e3885d4d https://github.com/NixOS/nixpkgs/commit/49561b8b650606ecab2ae954cf7b4765e3885d4d Author: Rene Donner c...@donner.at Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: R pkgs/development/compilers/julia/0.3.2.nix A pkgs/development/compilers/julia/0.3.3.nix M pkgs/top-level/all-packages.nix Log Message: --- julia - 0.3.3 Commit: b0dc5b17cac02e50e5595f00b9f83ef0f913994e https://github.com/NixOS/nixpkgs/commit/b0dc5b17cac02e50e5595f00b9f83ef0f913994e Author: Austin Seipp ase...@pobox.com Date: 2014-11-25 (Tue, 25 Nov 2014) Changed paths: A pkgs/tools/security/afl/default.nix M pkgs/top-level/all-packages.nix Log
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
Igor Pashev added the comment: Yes, Victor. Your patch works. All os tests are passed :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
Igor Pashev added the comment: errno is 25 (#define ENOTTY 25 /* Inappropriate ioctl for device */) It does not make sense to me to call unworkable ioctl() each time before other methods :-) I would consider adding a configure check for working ioctl() (but it won't work for cross compilation). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] Use FD_CLOEXEC in Python/fileutils.c
New submission from Igor Pashev: I've found on illumos-based OS that under some conditions python is unable to open any files because set_inheritable() fails. This happens even when building python when it cannot find (open) _sysconfigdata.py. The problem is that set_inheritable() first checks for FIOCLEX/FIONCLEX ioctls and tries to use them if such macros are defined. These macros can be defined at illumos, but kernel does not support them (inappropriate ioctl). Since other pieces of python already use FD_CLOEXEC unconditionally, including get_inheritable() I patched set_inheritable() to use FD_CLOEXEC. See attached patch. -- components: Build, IO files: dyson-set_inheritable.patch keywords: patch messages: 225745 nosy: igor.pashev priority: normal severity: normal status: open title: Use FD_CLOEXEC in Python/fileutils.c type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file36443/dyson-set_inheritable.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Igor Pashev added the comment: Related to http://bugs.python.org/issue8852 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Changes by Igor Pashev pashev.i...@gmail.com: Removed file: http://bugs.python.org/file34952/dyson-socketmodule-ifindex.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21287] Better support for AF_PACKET on opensolaris (illumos)
Changes by Igor Pashev pashev.i...@gmail.com: Added file: http://bugs.python.org/file34961/dyson-socketmodule-ifindex.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: GNU C extension: Function Error vs. Success
10.03.2014 18:27, Shahbaz Youssefi пишет: FILE *fin = fopen(filename, r) !! goto exit_no_file; Or maybe permission denied? ;-)
Bug#736950: fakeroot: Support Solaris ACLs, again
Package: fakeroot
Version: 1.20-3+dyson1
Severity: normal
Dear Maintainer,
please find a patch which makes fakeroot work perfectly on Dyson (Debian port
to the illumos (OpenSolaris) kernel) [1].
The attached patch makes three things:
1. Report errors from dlsym() only when debug is enabled. Since ACL functions
are not in libc or ld.so they are usually not found and illumos ld.so creates
noise.
2. Better detect ACL functions. Both Linux and illumos have acl_t and it's not
enough to check only this type. configure.ac patched to search ACL functions in
libacl (linux) and libsec (illumos).
3. Adds wrappers for illumos ACLs functions to fix bugs [2].
Also build dependencies should be fixed:
Build-Depends: sharutils,
libacl1-dev [!illumos-any],
libsec-dev [illumos-any],
libcap-dev [linux-any],
libcap2-bin [linux-any]
[1] http://osdyson.org
[2] http://osdyson.org/issues/167
-- System Information:
Debian Release: bok
Architecture: illumos-amd64 (i86pc)
Kernel: SunOS 5.11
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Versions of packages fakeroot depends on:
ii libc12.10+12
ii libfakeroot 1.20-3+dyson1
fakeroot recommends no packages.
fakeroot suggests no packages.
-- no debconf information
Description: support for illumos (solaris) ACLs
This patch makes GNU coreutils shut up and stops GNU sed
making files with permissions.
Bug-Dyson: http://osdyson.org/issues/167
Author: Igor Pashev pashev.i...@gmail.com
Index: fakeroot-1.20/libfakeroot.c
===
--- fakeroot-1.20.orig/libfakeroot.c 2014-01-27 21:22:04.0 +0400
+++ fakeroot-1.20/libfakeroot.c 2014-01-28 13:28:26.030053499 +0400
@@ -256,10 +256,12 @@
/* clear dlerror() just in case dlsym() legitimately returns NULL */
msg = dlerror();
*(next_wrap[i].doit)=dlsym(get_libc(), next_wrap[i].name);
+#ifdef LIBFAKEROOT_DEBUGGING
+/* illumos libc creates noise if symbols is not found (e. g. acl_get())*/
if ( (msg = dlerror()) != NULL){
fprintf (stderr, dlsym(%s): %s\n, next_wrap[i].name, msg);
-/*abort ();*/
}
+#endif /* LIBFAKEROOT_DEBUGGING */
}
}
@@ -1916,6 +1918,9 @@
}
#ifdef HAVE_ACL_T
+
+/* linux: */
+#ifdef HAVE_ACL_GET_FD
acl_t acl_get_fd(int fd) {
errno = ENOTSUP;
return (acl_t)NULL;
@@ -1928,12 +1933,51 @@
errno = ENOTSUP;
return -1;
}
-
int acl_set_file(const char *path_p, acl_type_t type, acl_t acl) {
errno = ENOTSUP;
return -1;
}
-#endif /* HAVE_SYS_ACL_H */
+#endif /* HAVE_ACL_GET_FD */
+
+/* illumos: */
+#ifdef HAVE_ACL_TRIVIAL
+int acl_get(const char *path, int flags, acl_t **aclp)
+{
+errno = ENOSYS;
+return -1;
+}
+int facl_get(int fd, int flags, acl_t **aclp)
+{
+errno = ENOSYS;
+return -1;
+}
+int acl_set(const char *path, acl_t *aclp)
+{
+errno = ENOSYS;
+return -1;
+}
+int facl_set(int fd, acl_t *aclp)
+{
+errno = ENOSYS;
+return -1;
+}
+int acl_trivial(const char *path)
+{
+return 0;
+}
+int acl(const char *path, int cmd, int cnt, void *buf)
+{
+errno = ENOSYS;
+return -1;
+}
+int facl(int fd, int cmd, int cnt, void *buf)
+{
+errno = ENOSYS;
+return -1;
+}
+#endif /* HAVE_ACL_TRIVIAL */
+
+#endif /* HAVE_ACL_T */
#ifdef HAVE_FTS_READ
FTSENT *fts_read(FTS *ftsp) {
Index: fakeroot-1.20/configure.ac
===
--- fakeroot-1.20.orig/configure.ac 2013-09-20 17:54:24.0 +0400
+++ fakeroot-1.20/configure.ac 2014-01-28 13:04:59.067226109 +0400
@@ -288,6 +288,16 @@
AC_CHECK_FUNCS(fchmodat fchownat fstatat mkdirat mknodat openat renameat unlinkat lchmod fgetattrlist)
+save_LIBS=$LIBS
+# Linux
+AC_SEARCH_LIBS(acl_get_fd, acl)
+AC_CHECK_FUNCS(acl_get_fd)
+
+# Illumos
+AC_SEARCH_LIBS(acl_trivial, sec)
+AC_CHECK_FUNCS(acl_trivial)
+LIBS=$save_LIBS
+
AC_CHECK_FUNCS(capset listxattr llistxattr flistxattr getxattr lgetxattr fgetxattr setxattr lsetxattr fsetxattr removexattr lremovexattr fremovexattr)
dnl find out how stat() etc are called. On linux systems, we really
Index: fakeroot-1.20/wrapfunc.inp
===
--- fakeroot-1.20.orig/wrapfunc.inp 2013-09-20 17:54:24.0 +0400
+++ fakeroot-1.20/wrapfunc.inp 2014-01-28 13:22:39.411221945 +0400
@@ -208,10 +208,24 @@
#endif /* HAVE_FSTATAT */
#ifdef HAVE_ACL_T
+
+#ifdef HAVE_ACL_GET_FD
acl_get_fd;acl_t;(int fd);(fd)
acl_get_file;acl_t;(const char *path_p, acl_type_t type);(path_p, type)
acl_set_fd;int;(int fd, acl_t acl);(fd, acl)
acl_set_file;int;(const char *path_p, acl_type_t type, acl_t acl);(path_p, type, acl)
+#endif
+
+#ifdef HAVE_ACL_TRIVIAL
+acl_get;int;(const char *path, int flags, acl_t **aclp);(path, flags, aclp)
+facl_get;int;(int fd, int flags, acl_t **aclp);(fd, flags, aclp)
+acl_set;int;(const char *path, acl_t *aclp);(path, aclp)
+facl_set;int;(int fd, acl_t *aclp);(fd, aclp
Bug#734473: synaptic: Portability issues (FTBFS on Dyson)
Package: synaptic
Version: 0.80.4+dyson1
Severity: normal
Dear Maintainer,
please find patches which fix some portability issues:
dyson-rindex.patch: rindex() is defined in strings.h [rindex]
dyson-bzero.patch: bzero() is legacy, replace with memset() [bzero]
dyson-fcntl.patch: fcntl(0 is defined in fcntl.h [fcntl]
With these patches applied it is possible to rebuild Synaptic on Dyson
without changes [dyson]
[rindex] http://pubs.opengroup.org/onlinepubs/009695399/functions/rindex.html
[bzero] http://pubs.opengroup.org/onlinepubs/009695399/functions/bzero.html
[fcntl] http://pubs.opengroup.org/onlinepubs/009695399/functions/fcntl.html
[dyson] http://osdyson.org/
P. S. Sent from Dyson :-)
-- System Information:
Debian Release: bok
Architecture: illumos-amd64 (i86pc)
Kernel: SunOS 5.11
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Versions of packages synaptic depends on:
ii hicolor-icon-theme 0.12-1
ii libapt-inst1.5 0.9.7.5+dyson3
ii libapt-pkg4.12 0.9.7.5+dyson3
ii libatk1.0-0 2.8.0-2+dyson1
ii libc12.10+12
ii libcairo-gobject21.12.16-2+dyson1
ii libcairo21.12.16-2+dyson1
ii libept1.4.12 1.0.9+dyson1
ii libgcc1 1:4.8.2-2+dyson1
ii libgdk-pixbuf2.0-0 2.28.2-1+dyson1
ii libglib2.0-0 2.36.3-3+dyson2
ii libgtk-3-0 3.8.2-3+dyson1
ii libm20.2.1
ii libpango-1.0-0 1.32.5-5+dyson1
ii libpangocairo-1.0-0 1.32.5-5+dyson1
ii libstdc++6 4.8.2-2+dyson1
ii libvte-2.90-91:0.34.6-1+dyson1
ii libx11-6 2:1.6.2-1+dyson1
ii libxapian22 1.2.8-1+dyson1
ii libxext0 2:1.3.0-3+dyson1
ii zlib1g 1:1.2.8.dfsg-1+dyson1
Versions of packages synaptic recommends:
ii gksu 2.0.2-6+dyson1
pn libgtk2-perl none
ii policykit-10.105-3+dyson2
ii rarian-compat 0.8.1-5+dyson1
Versions of packages synaptic suggests:
pn apt-xapian-index none
pn deborphannone
pn dwww none
ii menu 2.1.46+dyson1
pn software-properties-gtk none
pn tasksel none
-- no debconf information
Index: synaptic-0.80.4+dyson1/common/rpackagefilter.cc
===
--- synaptic-0.80.4+dyson1.orig/common/rpackagefilter.cc 2012-07-12 23:13:41.0 +0400
+++ synaptic-0.80.4+dyson1/common/rpackagefilter.cc 2014-01-07 12:26:34.353004966 +0400
@@ -28,6 +28,7 @@
#include algorithm
#include cstdio
#include fnmatch.h
+#include strings.h
#include apt-pkg/configuration.h
#include apt-pkg/strutl.h
#include apt-pkg/error.h
Index: synaptic-0.80.4+dyson1/gtk/rgdebinstallprogress.cc
===
--- synaptic-0.80.4+dyson1.orig/gtk/rgdebinstallprogress.cc 2012-11-21 22:54:58.0 +0400
+++ synaptic-0.80.4+dyson1/gtk/rgdebinstallprogress.cc 2014-01-07 12:30:00.935776801 +0400
@@ -152,7 +152,7 @@
// open connection to server
struct sockaddr_un servaddr;
int serverfd = socket(AF_LOCAL, SOCK_STREAM, 0);
- bzero(servaddr, sizeof(servaddr));
+ memset(servaddr, 0, sizeof(servaddr));
servaddr.sun_family = AF_LOCAL;
strcpy(servaddr.sun_path, UNIXSTR_PATH);
@@ -181,7 +181,7 @@
fcntl(listenfd, F_SETFL, O_NONBLOCK);
unlink(UNIXSTR_PATH);
- bzero(servaddr, sizeof(servaddr));
+ memset(servaddr, 0, sizeof(servaddr));
servaddr.sun_family = AF_LOCAL;
strcpy(servaddr.sun_path, UNIXSTR_PATH);
bind(listenfd, (struct sockaddr *)servaddr, sizeof(servaddr));
Index: synaptic-0.80.4+dyson1/gtk/rginstallprogress.cc
===
--- synaptic-0.80.4+dyson1.orig/gtk/rginstallprogress.cc 2012-01-30 15:24:22.0 +0400
+++ synaptic-0.80.4+dyson1/gtk/rginstallprogress.cc 2014-01-07 12:29:08.328087514 +0400
@@ -123,7 +123,7 @@
void RGInstallProgress::finishUpdate()
{
char buf[1024];
- bzero(buf, 1024);
+ memset(buf, 0, 1024);
int len = read(_childin, buf, 1023);
if (len 0) {
GtkWidget *dia = gtk_message_dialog_new(GTK_WINDOW(this-window()),
Index: synaptic-0.80.4+dyson1/common/raptoptions.cc
===
--- synaptic-0.80.4+dyson1.orig/common/raptoptions.cc 2012-06-11 19:31:11.0 +0400
+++ synaptic-0.80.4+dyson1/common/raptoptions.cc 2014-01-07 12:30:20.749340671 +0400
@@ -192,7 +192,7 @@
if ((point = strrchr(dent-d_name, '.')) == NULL)
continue;
if (strcmp(point, configext) == 0) {
- bzero(point, strlen(point));
+ memset(point, 0, strlen(point));
//cout (dent-d_name) endl;
setPackageDebconf(dent-d_name, true);
}
Index: synaptic-0.80.4+dyson1/common/rcdscanner.cc
===
---
Accepted open-axiom 1.5.0~svn3056+ds-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 15 Dec 2013 12:11:38 +0400 Source: open-axiom Binary: open-axiom open-axiom-source open-axiom-test open-axiom-databases open-axiom-tex open-axiom-graphics open-axiom-graphics-data open-axiom-hypertex open-axiom-hypertex-data Architecture: source i386 all Version: 1.5.0~svn3056+ds-1 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: open-axiom - open scientific computation platform open-axiom-databases - open scientific computation platform: generated text databases open-axiom-graphics - open scientific computation platform: graphics subsystem open-axiom-graphics-data - open scientific computation platform: graphics subsystem data open-axiom-hypertex - open scientific computation platform: hypertex subsystem open-axiom-hypertex-data - open scientific computation platform: hypertex subsystem data open-axiom-source - open scientific computation platform: source files open-axiom-test - open scientific computation platform: regression test inputs open-axiom-tex - open scientific computation platform: style file for TeX Changes: open-axiom (1.5.0~svn3056+ds-1) unstable; urgency=low . * New upstream version. * Use xz compression for both source tarball and packages * Require g++ = 4.7 for C++11 * Refreshed patches * touch aclocal.m4 -r configure.ac to avoid rebuilding aclocal.m4 which requires aclocal 1.13 * Do not patch configure.ac, but override variables in Makefiles (due to automake 1.13 too) * Require SBCL * Enable hardening (include /usr/share/dpkg/buildflags.mk for build flags) * Use dh-buildinfo * Override hardening-no-relro on usr/lib/open-axiom/bin/AXIOMsys * Build depends on autotools-dev to update config.* * Fixed get-orig-source target to work out of source tree * Use canonical VCS fields * Added keywords to d/open-axiom.desktop * Added description to non-static-open-axiom-binary.patch and no-missing-messages.patch * Updated d/copyright (thanks to Boris Pek) * Updated d/watch to use SourceForge SVN repository * Omit contrib directory (that's why +ds): - Unclear licenses (GPL, but which one?) - It is for Windows * Bump standards version 3.9.3 → 3.9.4, no changes Checksums-Sha1: 5666bd1b1c1f5c068f39a98761a0d8a5eb88f2de 2533 open-axiom_1.5.0~svn3056+ds-1.dsc a56a6794671f1da625f5a9fa10d4deaa0c981cab 8013156 open-axiom_1.5.0~svn3056+ds.orig.tar.xz ddcb386d765ed95c954e156cb6c9e77c7455b6cf 15527 open-axiom_1.5.0~svn3056+ds-1.debian.tar.gz b04041d96dd0876482fb67f832f224b2e8e19859 14758840 open-axiom_1.5.0~svn3056+ds-1_i386.deb 1d54e7097b79f07ce3c68629c7af4eb7dc5d4fbc 863910 open-axiom-source_1.5.0~svn3056+ds-1_all.deb 275b60ddeabe77eff7e06325eb745c42e2d1bb8e 150064 open-axiom-test_1.5.0~svn3056+ds-1_all.deb 26e447e9dc6a8b2a5c4f4dacc43a1fe3f5620a6d 937504 open-axiom-databases_1.5.0~svn3056+ds-1_all.deb 954325d1f8885abce841e0d58148c0304291bc12 8226 open-axiom-tex_1.5.0~svn3056+ds-1_all.deb e59173e5c394d155a0bae89fc6fed9f559480090 108946 open-axiom-graphics_1.5.0~svn3056+ds-1_i386.deb 86d9c47a91834851ec35aef7cda2af65c711e17c 11096 open-axiom-graphics-data_1.5.0~svn3056+ds-1_all.deb 22262cbc551cfcb4d721c4e26f4ee0560d743764 85952 open-axiom-hypertex_1.5.0~svn3056+ds-1_i386.deb 787e7377489f1a7f1ac7cc0aa89d30de36243e03 1039016 open-axiom-hypertex-data_1.5.0~svn3056+ds-1_all.deb Checksums-Sha256: ba15991610f7a4ac7132e7785c41b9bdce99870892fffc356575d7b4213d5ac7 2533 open-axiom_1.5.0~svn3056+ds-1.dsc b0fad736688ebd33c584736146a10543752a08bc24d79812507eeafe7620da6d 8013156 open-axiom_1.5.0~svn3056+ds.orig.tar.xz 6e6665013b8e7bc0e742b17bcaa468709f2af375f3e05e7398aaef4fb64b 15527 open-axiom_1.5.0~svn3056+ds-1.debian.tar.gz 68332054b13dc408ad26b65835fd762836f04ef23b4d03272d2fac568c217624 14758840 open-axiom_1.5.0~svn3056+ds-1_i386.deb 09e1c16bd4cf942274bd0c796dca9fda2d549b2bb0c8011ab3c6920abb2e39fc 863910 open-axiom-source_1.5.0~svn3056+ds-1_all.deb c7a7cc1366f847f5edd4c44740d35c97c0219a3bf3c54bdb69e5a74dc4bc9b48 150064 open-axiom-test_1.5.0~svn3056+ds-1_all.deb 14c0990c4e4638110ce7474c21135e618c35695d9501f354252ae136abbbd83d 937504 open-axiom-databases_1.5.0~svn3056+ds-1_all.deb b70a502eed75a25f9ece21e66f1e7ca3bfe13d8914b05eeebfccc51e675fc24b 8226 open-axiom-tex_1.5.0~svn3056+ds-1_all.deb c799e2d8066bcea7031cdbf507156f91d82b141f5e12d50d1b8ac9c88b0ed4c6 108946 open-axiom-graphics_1.5.0~svn3056+ds-1_i386.deb d0d20b4d734bfaff8d03630f570421e63ff333fdcd1b124f7728c199dc95f52f 11096 open-axiom-graphics-data_1.5.0~svn3056+ds-1_all.deb 713239a4a6d86164fe8e206cda24dce4e0133b22bc1d80dc847cfeec7a7e0cd7 85952 open-axiom-hypertex_1.5.0~svn3056+ds-1_i386.deb cd95c586bdd1ba675f51291650115f2fc3eedec5232eb34219087ea2e6e8ac0d 1039016 open-axiom-hypertex-data_1.5.0~svn3056+ds-1_all.deb Files: 5d5c59b9f04e10af0ee1e616f17a6105 2533
Bug#714244: ecl: New upstream release (13.5.1)
Package: ecl Version: 11.1.1+dfsg1-2 Severity: normal Dear Maintainer, new upstream release of ECL is available at version 13.5.1 This version is known to work for building OpenAxiom. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ecl depends on: ii gcc 4:4.7.2-1 ii libc62.13-38 ii libgc-dev1:7.1-9.1 ii libgc1c2 1:7.1-9.1 ii libgmp10 2:5.0.5+dfsg-2 ii libgmp3-dev 2:5.0.5+dfsg-2 ii libncurses5-dev 5.9-10 ecl recommends no packages. Versions of packages ecl suggests: pn ecl-doc none pn slimenone -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714244: ecl: New upstream release (13.5.1)
Package: ecl Version: 11.1.1+dfsg1-2 Severity: normal Dear Maintainer, new upstream release of ECL is available at version 13.5.1 This version is known to work for building OpenAxiom. -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ecl depends on: ii gcc 4:4.7.2-1 ii libc62.13-38 ii libgc-dev1:7.1-9.1 ii libgc1c2 1:7.1-9.1 ii libgmp10 2:5.0.5+dfsg-2 ii libgmp3-dev 2:5.0.5+dfsg-2 ii libncurses5-dev 5.9-10 ecl recommends no packages. Versions of packages ecl suggests: pn ecl-doc none pn slimenone -- no debconf information ___ pkg-common-lisp-devel mailing list pkg-common-lisp-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
Bug#701173: screen fails to start is terminal device is a symlink
Package: screen
Version: 4.1.0~20120320gitdb59704-7
Severity: normal
Dear Maintainer,
screen is patched to check terminal it is starting on (debian/patches/47screen-
cc.patch)
Terminal device is required to be a normal character device, but it is not
always the case.
E. g. on illumos/solaris /dev/console is a symbolic link to
/devices/pseudo/cn@0:console
I'm attaching a patch which adjusts the check for symlinks.
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages screen depends on:
ii dpkg 1.16.9
ii install-info 4.13a.dfsg.1-10
ii libc6 2.13-37
ii libpam0g 1.1.3-7.1
ii libtinfo5 5.9-10
screen recommends no packages.
Versions of packages screen suggests:
pn iselect | screenie | byobu none
-- debconf information excluded
Description: /dev/console may be a symlink
See http://lists.debian.org/debian-devel/2013/01/msg00576.html
In case of SunOS kernel (illumos) it is not possible for a device
file to have st_nlink != 1, so do not bother with /devices/
Index: screen/tty.sh
===
--- screen.orig/tty.sh 2013-01-27 02:16:57.916935245 +
+++ screen/tty.sh 2013-01-27 02:33:12.831241123 +
@@ -1506,11 +1506,21 @@
char *tty;
{
struct stat st;
+ char * real;
+ int rc;
- if (lstat(tty, st) || !S_ISCHR(st.st_mode) ||
- (st.st_nlink 1 strncmp(tty, /dev/, 5)))
+ real = realpath(tty, NULL);
+ if (!real)
return -1;
- return 0;
+
+ if (lstat(real, st) || !S_ISCHR(st.st_mode) ||
+(st.st_nlink 1 strncmp(real, /dev/, 5)))
+rc = -1;
+ else
+rc = 0;
+
+ free(real);
+ return rc;
}
/*
Bug#699219: icon: New upstream version, git, 3.0 (quilt) format
Source: icon Severity: wishlist Dear Maintainer, I've adopted icon for the 3.0 (quilt) fromat, created git repository, and updated to the lastest upstream version (9.5.0): http://git.osdyson.org/?p=icon.git Notable change: iconc is removed. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695589: x11proto-core-dev: upstream patch for g++ restrict issue on solaris
Package: x11proto-core-dev Version: 7.0.23-1 Severity: minor Dear Maintainer, please, apply the upstream patch to fix g++ restrict issue on solaris: https://bugs.freedesktop.org/show_bug.cgi?id=51009 https://bugs.freedesktop.org/attachment.cgi?id=66181 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages x11proto-core-dev depends on: ii xorg-sgml-doctools 1:1.10-1 x11proto-core-dev recommends no packages. x11proto-core-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695589: x11proto-core-dev: upstream patch for g++ restrict issue on solaris
Package: x11proto-core-dev Version: 7.0.23-1 Severity: minor Dear Maintainer, please, apply the upstream patch to fix g++ restrict issue on solaris: https://bugs.freedesktop.org/show_bug.cgi?id=51009 https://bugs.freedesktop.org/attachment.cgi?id=66181 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages x11proto-core-dev depends on: ii xorg-sgml-doctools 1:1.10-1 x11proto-core-dev recommends no packages. x11proto-core-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121210132721.1045.63013.reportbug@localhost
Bug#689656: [Pkg-javascript-devel] Bug#689656: nodejs: Patches for GNU/sunos
25.10.2012 12:15, Jérémy Lal пишет: I see no problem in applying that patch, but I'd like to understand if that patch can be forwarded upstream or not. Do you know why upstream choose those options for sunos ? I think upstream will not accept these patches. Node.js is developed by Joyent, and Joyent is all about illumos (aka Opensolaris). So there are at least three reasons not to accept patches: 1. GNU? Why do we need to take care of third-party software? 2. We have our own cool link-editor, you should use it on `sunos` . 3. Our build system is badly broken to support this [1] I know those guys well enough :-) (-threads options was dropped since GCC 4.7) [1] https://github.com/joyent/illumos-extra/commit/fc553cb0b9f3668ca6fa04c49fff5ebbed387583 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Pkg-javascript-devel] Bug#689656: Bug#689656: nodejs: Patches for GNU/sunos
25.10.2012 12:15, Jérémy Lal пишет: I see no problem in applying that patch, but I'd like to understand if that patch can be forwarded upstream or not. Do you know why upstream choose those options for sunos ? I think upstream will not accept these patches. Node.js is developed by Joyent, and Joyent is all about illumos (aka Opensolaris). So there are at least three reasons not to accept patches: 1. GNU? Why do we need to take care of third-party software? 2. We have our own cool link-editor, you should use it on `sunos` . 3. Our build system is badly broken to support this [1] I know those guys well enough :-) (-threads options was dropped since GCC 4.7) [1] https://github.com/joyent/illumos-extra/commit/fc553cb0b9f3668ca6fa04c49fff5ebbed387583 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#690137: libpcap0.8: Add version tags into linker version script
Package: libpcap0.8 Version: 1.3.0-1 Severity: normal Dear Maintainer, libpcap is patched to use version script, but symbols in that script are not tagged. It might be a problem since GNU ld does not allow mixing tagged and untagged (anonymous) symbols. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpcap0.8 depends on: ii libc6 2.13-35 ii multiarch-support 2.13-35 libpcap0.8 recommends no packages. libpcap0.8 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690061: reprepro: Stack damage if not using libarchive
Package: reprepro
Version: 4.12.4-1
Severity: important
Dear Maintainer,
file extractcontrol.c is used when building reprepro without libarchive. This
file uses function chunk_extract() *without* prototype defined in chunks.h
(not included).
This results in compiler warning about implicit declaration of function
chunk_extract(), but real problem is much more serious: chunk_extract() accepts
5 arguments, and in extractcontrol.c only 4 are passed.
I'm sending a patch fixing this issue.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages reprepro depends on:
ii libarchive12 3.0.4-2
ii libbz2-1.0 1.0.6-4
ii libc6 2.13-35
ii libdb5.1 5.1.29-5
ii libgpg-error0 1.10-3.1
ii libgpgme11 1.2.0-1.4
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages reprepro recommends:
ii apt 0.9.7.5
Versions of packages reprepro suggests:
pn gnupg-agent none
pn inoticoming none
ii lzip 1.13-3
ii lzma 9.22-2
ii xz-utils [lzma] 5.1.1alpha+20120614-1
-- no debconf information
diff --git a/extractcontrol.c b/extractcontrol.c
index 369192a..f90188a 100644
--- a/extractcontrol.c
+++ b/extractcontrol.c
@@ -29,6 +29,7 @@
#include filecntl.h
#include readtextfile.h
#include debfile.h
+#include chunks.h
#ifdef HAVE_LIBARCHIVE
#error Why did this file got compiled instead of debfile.c?
@@ -139,6 +140,7 @@ static retvalue try_extractcontrol(char **control, const char *debfile, bool bro
if (RET_IS_OK(r)) {
len = chunk_extract(controlchunk,
controlchunk, controllen,
+ true,
afterchanges);
if (len == 0)
r = RET_NOTHING;
Bug#689708: reprepro: Capital 'X' in messages, but real option is small 'x'
Package: reprepro Version: 4.12.4-1 Severity: minor Dear Maintainer, reprepro uses capital 'X' as tar parameter in messages, but real option is small 'x': http://anonscm.debian.org/gitweb/?p=mirrorer/reprepro.git;a=blob;f=extractcontrol.c;h=369192a6ae4466c273d0e870021d50daed9dc0a6;hb=HEAD#l136 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reprepro depends on: ii libarchive12 3.0.4-2 ii libbz2-1.0 1.0.6-4 ii libc6 2.13-35 ii libdb5.1 5.1.29-5 ii libgpg-error0 1.10-3.1 ii libgpgme11 1.2.0-1.4 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages reprepro recommends: ii apt 0.9.7.5 Versions of packages reprepro suggests: pn gnupg-agent none pn inoticoming none pn lzip none ii lzma 9.22-2 ii xz-utils [lzma] 5.1.1alpha+20120614-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689656: nodejs: Patches for GNU/sunos
Package: nodejs
Version: 0.6.19~dfsg1-5
Severity: normal
Dear Maintainer,
I'm porting Debian on illumos kernel and using GNU toolchain (GCC, binutils,
etc.)
Node.js' build system sucks so much that cannot detect features of the compiler
and the linker. Instead it tests the platform.
It assumes, that on sunos linker always exports all dynamic symbols. It is
true for sunos linker, but not for GNU ld - the latter need --export-dynamic,
or -rdynamic option to GCC.
Another issue is that Node.js' build system passes -threads options to the
compiler. GCC does not support it.
I believe Debian on any kernel will use GNU tools, thus these patches can be
adopted by Node.js package.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nodejs depends on:
ii libc-ares2 1.9.1-3
ii libc6 2.13-35
ii libev4 1:4.11-1
ii libgcc1 1:4.7.1-7
ii libssl1.0.0 1.0.1c-4
ii libstdc++6 4.7.1-7
ii libv8-3.8.9.20 3.8.9.20-1
ii zlib1g 1:1.2.7.dfsg-13
nodejs recommends no packages.
nodejs suggests no packages.
-- no debconf information
From: Igor Pashev pashev.i...@gmail.com
Date: Tue, 21 Aug 2012 16:22:14 +
Subject: Dyson: do not pass -threads to compiler
---
wscript |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/wscript b/wscript
index f922ad1..f128fdf 100644
--- a/wscript
+++ b/wscript
@@ -491,9 +491,7 @@ def configure(conf):
conf.define(HAVE_CONFIG_H, 1)
if sys.platform.startswith(sunos):
-conf.env.append_value ('CCFLAGS', '-threads')
-conf.env.append_value ('CXXFLAGS', '-threads')
-#conf.env.append_value ('LINKFLAGS', ' -threads')
+ pass
elif not sys.platform.startswith(win32):
threadflags='-pthread'
conf.env.append_value ('CCFLAGS', threadflags)
From: Igor Pashev pashev.i...@gmail.com
Date: Tue, 21 Aug 2012 16:26:33 +
Subject: Dyson: allow -rdynamic
---
wscript |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wscript b/wscript
index f128fdf..b64449b 100644
--- a/wscript
+++ b/wscript
@@ -318,7 +318,7 @@ def configure(conf):
conf.env['USE_NPM'] = not o.without_npm
conf.check(lib='dl', uselib_store='DL')
- if not sys.platform.startswith(sunos) and not sys.platform.startswith(win32):
+ if not sys.platform.startswith(win32):
conf.env.append_value(CCFLAGS, -rdynamic)
conf.env.append_value(LINKFLAGS_DL, -rdynamic)
[Pkg-javascript-devel] Bug#689656: nodejs: Patches for GNU/sunos
Package: nodejs
Version: 0.6.19~dfsg1-5
Severity: normal
Dear Maintainer,
I'm porting Debian on illumos kernel and using GNU toolchain (GCC, binutils,
etc.)
Node.js' build system sucks so much that cannot detect features of the compiler
and the linker. Instead it tests the platform.
It assumes, that on sunos linker always exports all dynamic symbols. It is
true for sunos linker, but not for GNU ld - the latter need --export-dynamic,
or -rdynamic option to GCC.
Another issue is that Node.js' build system passes -threads options to the
compiler. GCC does not support it.
I believe Debian on any kernel will use GNU tools, thus these patches can be
adopted by Node.js package.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nodejs depends on:
ii libc-ares2 1.9.1-3
ii libc6 2.13-35
ii libev4 1:4.11-1
ii libgcc1 1:4.7.1-7
ii libssl1.0.0 1.0.1c-4
ii libstdc++6 4.7.1-7
ii libv8-3.8.9.20 3.8.9.20-1
ii zlib1g 1:1.2.7.dfsg-13
nodejs recommends no packages.
nodejs suggests no packages.
-- no debconf information
From: Igor Pashev pashev.i...@gmail.com
Date: Tue, 21 Aug 2012 16:22:14 +
Subject: Dyson: do not pass -threads to compiler
---
wscript |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/wscript b/wscript
index f922ad1..f128fdf 100644
--- a/wscript
+++ b/wscript
@@ -491,9 +491,7 @@ def configure(conf):
conf.define(HAVE_CONFIG_H, 1)
if sys.platform.startswith(sunos):
-conf.env.append_value ('CCFLAGS', '-threads')
-conf.env.append_value ('CXXFLAGS', '-threads')
-#conf.env.append_value ('LINKFLAGS', ' -threads')
+ pass
elif not sys.platform.startswith(win32):
threadflags='-pthread'
conf.env.append_value ('CCFLAGS', threadflags)
From: Igor Pashev pashev.i...@gmail.com
Date: Tue, 21 Aug 2012 16:26:33 +
Subject: Dyson: allow -rdynamic
---
wscript |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wscript b/wscript
index f128fdf..b64449b 100644
--- a/wscript
+++ b/wscript
@@ -318,7 +318,7 @@ def configure(conf):
conf.env['USE_NPM'] = not o.without_npm
conf.check(lib='dl', uselib_store='DL')
- if not sys.platform.startswith(sunos) and not sys.platform.startswith(win32):
+ if not sys.platform.startswith(win32):
conf.env.append_value(CCFLAGS, -rdynamic)
conf.env.append_value(LINKFLAGS_DL, -rdynamic)
___
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [discuss] sgml2roff - 3241 removal of sgml2roff breaks JDS build
My point is all these consolidations and gates are not the way to go. divide and conquer! 30.09.2012 18:13, Milan Jurik пишет: Hi, before continuing in ping-pong about this: https://www.illumos.org/issues/3241 I would like to see discussion on the list. Status is that JDS gate is broken by removal of sgml2roff. Yes, sgml2roff has no usage in Illumos gate. But that is not correct answer I believe. The changeset removed functionality used by some consumers. I know many people do not see benefit in maintaining JDS (and GUI) in Illumos based distro. Still I do not understand why Illumos should be stripped from functionality used by some consumers. Yes, not all parts need to be sitting in Illumos gate. But I do not see any vehicle which allows moving bits between consolidations for now. I would like to understand reason why sgml2roff was removed if the argument that it is not need by consumers is not valid. From my point of view it is regression in functionality. Best regards, Milan --- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/22130224-6cd34a13 Modify Your Subscription: https://www.listbox.com/member/?; Powered by Listbox: http://www.listbox.com --- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
Bug#689142: libossp-uuid16: libossp-uuid.so.* should not have unresolved symbols
Package: libossp-uuid16 Version: 1.6.2-1.3 Severity: normal Dear Maintainer, I discovered that postgress configure script fails to find required functions in libossp-uuid, because shared libraries are allowed to have unresolved symbols, but applications - not. So the simple test program generated by configure failed. On illumos libossp-uuid needs at least libsocket. So for portability it is desirable to link *library* with all requird system libraries. I'm sending you a (trivial) patch doing that. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libossp-uuid16 depends on: ii libc6 2.13-35 ii libgcc1 1:4.7.1-7 ii libstdc++6 4.7.1-7 libossp-uuid16 recommends no packages. Versions of packages libossp-uuid16 suggests: pn uuid none -- no debconf information Index: ossp-uuid-1.6.2/Makefile.in === --- ossp-uuid-1.6.2.orig/Makefile.in 2012-09-29 20:53:08.0 +0400 +++ ossp-uuid-1.6.2/Makefile.in 2012-09-29 21:06:24.183005853 +0400 @@ -112,7 +112,7 @@ @$(LIBTOOL) --mode=compile $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $ $(LIB_NAME): $(LIB_OBJS) - @$(LIBTOOL) --mode=link $(CC) -o $(LIB_NAME) $(LIB_OBJS) -rpath $(libdir) \ + @$(LIBTOOL) --mode=link $(CC) -o $(LIB_NAME) $(LIB_OBJS) $(LIBS) -rpath $(libdir) \ -version-info `$(SHTOOL) version -l c -d libtool $(S)/uuid_vers.h` $(DCE_NAME): $(DCE_OBJS)
Bug#688804: m4 can accidentally link to libsigsegv
Package: m4 Version: 1.4.16-3 Severity: normal Dear Maintainer, m4 configure script by default search for libsigsegv library and headers. And if found, m4 will be linked to that library. There is a configure option to disable this: --without-libsigsegv-prefix don't search for libsigsegv in includedir and libdir -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages m4 depends on: ii dpkg 1.16.8 ii install-info 4.13a.dfsg.1-10 ii libc6 2.13-35 m4 recommends no packages. m4 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688633: libpgm-5.1-0: Upstream portability patches
Package: libpgm-5.1-0
Version: 5.1.118-1~dfsg-0.1
Severity: normal
Dear Maintainer,
please consider to apply these upstream fixes, which make libpgm build and
correctly work on illumos (solaris).
http://code.google.com/p/openpgm/issues/detail?id=21
http://code.google.com/p/openpgm/issues/detail?id=25
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libpgm-5.1-0 depends on:
ii libc6 2.13-35
libpgm-5.1-0 recommends no packages.
libpgm-5.1-0 suggests no packages.
-- no debconf information
Description: configure incorrectly sets CONFIG_HAVE_IFR_NETMASK
Bug: http://code.google.com/p/openpgm/issues/detail?id=21
--- libpgm-5.1.118-1~dfsg.orig/openpgm/pgm/configure.ac 2011-09-27 17:59:08.0 +
+++ libpgm-5.1.118-1~dfsg/openpgm/pgm/configure.ac 2012-06-06 20:21:04.407905323 +
@@ -184,8 +184,8 @@
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM([[#include sys/types.h
#include ifaddrs.h]],
- [[struct ifaddrs ifa;
-ifa.ifa_netmask = (struct sockaddr*)0;]])],
+ [[struct ifreq ifr;
+ifr.ifr_netmask = (struct sockaddr*)0;]])],
[AC_MSG_RESULT([yes])
CFLAGS=$CFLAGS -DCONFIG_HAVE_IFR_NETMASK],
[AC_MSG_RESULT([no])])
Description: on illumos ifa_flags is uint64_t
Bug: http://code.google.com/p/openpgm/issues/detail?id=25
diff -dubr libpgm-5.1.118/openpgm/pgm/getifaddrs.c libpgm-5.1.118.flags/openpgm/pgm/getifaddrs.c
--- libpgm-5.1.118/openpgm/pgm/getifaddrs.c 2011-09-27 21:59:08.0 +0400
+++ libpgm-5.1.118.flags/openpgm/pgm/getifaddrs.c 2012-09-24 05:25:16.404925472 +0400
@@ -813,6 +813,68 @@
return TRUE;
}
#endif /* _WIN32 */
+#if defined( HAVE_GETIFADDRS )
+static
+bool
+_pgm_getifaddrs (
+ struct pgm_ifaddrs_t** restrict ifap,
+ pgm_error_t** restrict error
+ )
+{
+ struct ifaddrs *_ifap, *_ifa;
+ const int e = getifaddrs (_ifap);
+ if (-1 == e) {
+ char errbuf[1024];
+ pgm_set_error (error,
+ PGM_ERROR_DOMAIN_IF,
+ pgm_error_from_errno (errno),
+ _(getifaddrs failed: %s),
+ pgm_strerror_s (errbuf, sizeof (errbuf), errno));
+ return FALSE;
+ }
+
+ int n = 0, k = 0;
+ for (_ifa = _ifap; _ifa; _ifa = _ifa-ifa_next)
+ ++n;
+
+ struct _pgm_ifaddrs_t* ifa = pgm_new0 (struct _pgm_ifaddrs_t, n);
+ struct _pgm_ifaddrs_t* ift = ifa;
+ for (_ifa = _ifap; _ifa; _ifa = _ifa-ifa_next)
+ {
+/* ensure IP adapter */
+ if (NULL == _ifa-ifa_addr ||
+ (_ifa-ifa_addr-sa_family != AF_INET
+ _ifa-ifa_addr-sa_family != AF_INET6) )
+ {
+ continue;
+ }
+
+/* address */
+ ift-_ifa.ifa_addr = (void*)ift-_addr;
+ memcpy (ift-_ifa.ifa_addr, _ifa-ifa_addr, pgm_sockaddr_len (_ifa-ifa_addr));
+
+/* name */
+ ift-_ifa.ifa_name = ift-_name;
+ pgm_strncpy_s (ift-_ifa.ifa_name, IF_NAMESIZE, _ifa-ifa_name, _TRUNCATE);
+
+/* flags */
+ ift-_ifa.ifa_flags = _ifa-ifa_flags;
+
+/* netmask */
+ ift-_ifa.ifa_netmask = (void*)ift-_netmask;
+ memcpy (ift-_ifa.ifa_netmask, _ifa-ifa_netmask, pgm_sockaddr_len (_ifa-ifa_netmask));
+
+/* next */
+ if (k++ (n - 1)) {
+ ift-_ifa.ifa_next = (struct pgm_ifaddrs_t*)(ift + 1);
+ ift = (struct _pgm_ifaddrs_t*)(ift-_ifa.ifa_next);
+ }
+ }
+ freeifaddrs (_ifap);
+ *ifap = (struct pgm_ifaddrs_t*)ifa;
+ return TRUE;
+}
+#endif /* HAVE_GETIFADDRS */
/* returns TRUE on success setting ifap to a linked list of system interfaces,
* returns FALSE on failure and sets error appropriately.
@@ -830,17 +892,7 @@
(void*)ifap, (void*)error);
#ifdef CONFIG_HAVE_GETIFADDRS
- const int e = getifaddrs ((struct ifaddrs**)ifap);
- if (-1 == e) {
- char errbuf[1024];
- pgm_set_error (error,
-PGM_ERROR_DOMAIN_IF,
-pgm_error_from_errno (errno),
-_(getifaddrs failed: %s),
-pgm_strerror_s (errbuf, sizeof (errbuf), errno));
- return FALSE;
- }
- return TRUE;
+ return _pgm_getifaddrs (ifap, error);
#elif defined(CONFIG_TARGET_WINE)
return _pgm_getadaptersinfo (ifap, error);
#elif defined(_WIN32)
@@ -861,11 +913,7 @@
{
pgm_return_if_fail (NULL != ifa);
-#ifdef CONFIG_HAVE_GETIFADDRS
- freeifaddrs ((struct ifaddrs*)ifa);
-#else
pgm_free (ifa);
-#endif
}
/* eof */
Только в libpgm-5.1.118.flags/openpgm/pgm: getifaddrs.c.orig
[Bug 1054043] Re: List owner does not receive its posts
Holy cow! It is Gmail, indeed. Sorry for bothering you. ** Changed in: mailman Status: Incomplete = Invalid -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1054043 Title: List owner does not receive its posts To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1054043/+subscriptions ___ Mailman-coders mailing list Mailman-coders@python.org http://mail.python.org/mailman/listinfo/mailman-coders
Re: debian/rules stamp-* targets
03.09.2012 21:53, Arno Töll пишет: Hi, On 03.09.2012 18:55, The Wanderer wrote: I have not been able to find any documentation on these stamp-* targets, although searching has revealed that they or something like them appear to be (or to have been) used in a number of other packages as well. What are they used for, and how necessary are they? They are entirely optional, in fact. It's a custom behavior to work around issues with pseudo-phony targets which aren't declared as such for some reason [1]. That's just one way (among many) to implement a debian/rules file. I can also suggest to use *-stamp: such files will be removed by dh_clean automatically :-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5044fd55.5020...@gmail.com
Re: Minified javascript files
20.08.2012 11:33, Thomas Goirand пишет: So, could you tell in what way yui-compressor isn't considered not reliable enough? Does it crash? Or does it produce bad minified scripts? In which case: in what way bad? yui-compressor has a lot of dependencies :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5034cdb4.8010...@gmail.com
Re: Determine DEB_HOST_MULTIARCH without requiring dpkg-dev
25.07.2012 12:05, Michael Wild пишет: Hi all How can I reliably (from a user-program) determine the multiarch-triplet/quadlet without depending on dpkg-dev? I found some talk of a lsb_architecture utility, but so far have found no trace of it... # gcc -print-multiarch x86_64-linux-gnu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500fb975.4010...@gmail.com
Bug#681748: dwarfdump: Dwarfdump cannot read 64-bit object with thread-local data
Package: dwarfdump Version: 20120410-2 Severity: normal Dear Maintainer, I'm using dwarfdump and GCC on Debian (amd64). Dwarfdump cannot read debug info from 64-bit object file containing thread-local data. Error is DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN. I've checked this with GCC 4.5, 4.6, and 4.7 Here is the test suite: 1. File tls.c with single line: __thread int a; 2. File notls.c with single line: int a; 3. Make 4 object files: with/without tls, 32 and 64 bits: for m in 32 64; do for t in tls notls; do gcc -m$m -gdwarf-2 -c $t.c -o $t-$m.o ; done; done 4. Make dwarf dumps and elf dumps: for o in notls-32.o notls-64.o tls-32.o tls-64.o; do echo; echo === DWARF: $o =; dwarfdump $o; echo; echo === ELF: $o =; readelf -a $o; done data.log See attached data.log -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dwarfdump depends on: ii libc6 2.13-33 ii libelf1 0.152-1+b1 ii libgcc1 1:4.7.1-2 ii libstdc++6 4.7.1-2 dwarfdump recommends no packages. dwarfdump suggests no packages. -- no debconf information === DWARF: notls-32.o = ..debug_info COMPILE_UNIT: < 0><0x000b> DW_TAG_compile_unit DW_AT_producer "GNU C 4.7.1" DW_AT_language DW_LANG_C89 DW_AT_name "notls.c" DW_AT_comp_dir "/tmp" DW_AT_stmt_list 0x LOCAL_SYMBOLS: < 1><0x001d>DW_TAG_variable DW_AT_name "a" DW_AT_decl_file 0x0001 /tmp/notls.c DW_AT_decl_line 0x0001 DW_AT_type <0x002d> DW_AT_external yes(1) DW_AT_location DW_OP_addr 0x < 1><0x002d>DW_TAG_base_type DW_AT_byte_size 0x0004 DW_AT_encoding DW_ATE_signed DW_AT_name "int" ..debug_line: line number info for a single cu Source lines (from CU-DIE at .debug_info offset 0x000b): [row,col] NS BB ET PE EB IS= DI= uri: "filepath" NS new statement, BB new basic block, ET end of text sequence PE prologue end, EB epilogue begin IA=val ISA number, DI=val discriminator value ..debug_pubnames ..debug_macinfo ..debug_string name at offset 0x, length 11 is 'GNU C 4.7.1' name at offset 0x000c, length4 is '/tmp' name at offset 0x0011, length7 is 'notls.c' ..debug_aranges arange end ..debug_frame ..debug_static_func ..debug_static_vars ..debug_weaknames === ELF: notls-32.o = ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 408 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 40 (bytes) Number of section headers: 16 Section header string table index: 13 Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .text PROGBITS 34 00 00 AX 0 0 4 [ 2] .data PROGBITS 34 00 00 WA 0 0 4 [ 3] .bss NOBITS 34 00 00 WA 0 0 4 [ 4] .debug_info PROGBITS 34 35 00 0 0 1 [ 5] .rel.debug_info REL 0004f4 30 08 14 4 4 [ 6] .debug_abbrev PROGBITS 69 2c 00 0 0 1 [ 7] .debug_arangesPROGBITS 95 18 00 0 0 1 [ 8] .rel.debug_arange REL 000524 08 08 14 7 4 [ 9] .debug_line PROGBITS ad 28 00 0 0 1 [10] .debug_strPROGBITS
Bug#677207: ispell: Logical error in debian/packages.d/gen_debhelper_files.pl
Package: ispell Version: 3.3.02-5 Severity: normal Dear Maintainer, file debian/packages.d/gen_debhelper_files.pl at line 57 reads: die Cannot find debian dir unless $#debdirs 1; but should: die Cannot find debian dir if $#debdirs 1; -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ispell depends on: ii dictionaries-common 1.12.8 ii libc62.13-32 ii libncurses5 5.9-7 Versions of packages ispell recommends: ii irussian [ispell-dictionary] 0.99g5-18 ii wamerican [wordlist] 7.1-1 Versions of packages ispell suggests: pn spell none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677275: passwd: RAND_MAX is for rand() only, and on some systems random() can exceed RAND_MAX
Package: passwd Version: 1:4.1.5.1-1 Severity: wishlist Dear Maintainer, function SHA_salt_size() in file libmisc/salt.c uses random() to get random number and divides it by RAND_MAX. This is incorrect. RAND_MAX macro is designed for C standard fucntion rand() (value of the RAND_MAX macro shall be at least 32767) [1] But random() returns numbers in the range from 0 to 2^31-1 [2]. So, random()/RAND_MAX could result in a value 1. I propose to replace RAND_MAX with LONG_MAX. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/rand.html [2] http://pubs.opengroup.org/onlinepubs/7908799/xsh/initstate.html -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages passwd depends on: ii debianutils 4.3.1 ii libc6 2.13-33 ii libpam-modules 1.1.3-7.1 ii libpam0g1.1.3-7.1 ii libselinux1 2.1.9-2 ii libsemanage12.1.6-2 passwd recommends no packages. passwd suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675824: shadow: possible segfault in useradd
Package: shadow
Version: passwd
Severity: normal
Dear Maintainer,
Function __pw_dup() in lib/pwmem.c allocates uninitialized memory for struct
passwd and then fills some members of that struct, but other members (e. g.
pw_age) are still uninitialized. It can results in segfault in putpwent() which
tests for pw_age.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Index: shadow-4.1.5/lib/pwmem.c
===
--- shadow-4.1.5.orig/lib/pwmem.c 2009-09-07 19:08:21.0 +
+++ shadow-4.1.5/lib/pwmem.c 2012-06-03 18:39:48.377996169 +
@@ -44,7 +44,7 @@
{
struct passwd *pw;
- pw = (struct passwd *) malloc (sizeof *pw);
+ pw = (struct passwd *) calloc (1, sizeof *pw);
if (NULL == pw) {
return NULL;
}
Bug#675367: pristine-tar: fts.h is not required to build pristine-tar
Package: pristine-tar Version: 1.24 Severity: minor Dear Maintainer, I'm building pristine-tar on Illumos platform and have no fts.h header. This header is a part of glibc and libast (on Illumos/Solaris). But the fact is that no definitions from this file are used in pristine-tar. So it is safe to remove #include fts.h from ./zgz/zgz.c, thus it makes pristine-tar more portable. Sure, I did test the build on illumos and on Debian. Thanks :-) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pristine-tar depends on: ii libbz2-1.01.0.6-1 ii libc6 2.13-32 ii perl-modules 5.14.2-11 ii xdelta1.1.3-9 ii zlib1g1:1.2.7.dfsg-1 Versions of packages pristine-tar recommends: ii bzip2 1.0.6-1 ii pbzip21.1.6-1 ii xz-utils 5.1.1alpha+20110809-3 pristine-tar suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted rocksndiamonds 3.3.0.1+dfsg1-2.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 13 May 2012 19:44:35 +0400 Source: rocksndiamonds Binary: rocksndiamonds Architecture: source amd64 Version: 3.3.0.1+dfsg1-2.2 Distribution: unstable Urgency: low Maintainer: Dmitry E. Oboukhov un...@debian.org Changed-By: Igor Pashev pashev.i...@gmail.com Description: rocksndiamonds - arcade-style game Closes: 651620 Changes: rocksndiamonds (3.3.0.1+dfsg1-2.2) unstable; urgency=low . * Non-maintainer upload. * Fixed permissions when creating directories (Closes: #651620) Checksums-Sha1: 493978d9aa9d1872a96c3161dfed75607d502bb6 2164 rocksndiamonds_3.3.0.1+dfsg1-2.2.dsc f70727c8a67b22dd083695300544f92551f53c1f 22017 rocksndiamonds_3.3.0.1+dfsg1-2.2.debian.tar.gz 536346a00c7e8a1e50de63b6cfacdb813d1af407 539106 rocksndiamonds_3.3.0.1+dfsg1-2.2_amd64.deb Checksums-Sha256: 838331a8d89d72abd212bd1da50dd3a7e9d710b243205d87465455953bf69a14 2164 rocksndiamonds_3.3.0.1+dfsg1-2.2.dsc 3a48329d48b4e685d555f4764a68a542e3076f78936db588cfbbfc192d70e552 22017 rocksndiamonds_3.3.0.1+dfsg1-2.2.debian.tar.gz e836e3ac734d2b87acf21e198871dc6bb91cfc2c0931bd9b9c8d9a4e08658567 539106 rocksndiamonds_3.3.0.1+dfsg1-2.2_amd64.deb Files: c4ba867d38fc68aec13d61eef052ea76 2164 contrib/games extra rocksndiamonds_3.3.0.1+dfsg1-2.2.dsc f98930cc2f7ba31620073d0277637509 22017 contrib/games extra rocksndiamonds_3.3.0.1+dfsg1-2.2.debian.tar.gz 4bd0fdaaff67c24fe4849dc99cfc354c 539106 contrib/games extra rocksndiamonds_3.3.0.1+dfsg1-2.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJPt5eZAAoJEDNV9NY7WCHMWyEQAInlW5mWUaMf18tLhM5d/lC3 DJDEdwot+k6B4dnC1UlfkwCPlw+HFxvdrSwF+CC+1A/NiBtPabgu4bCYNdmtDJMj RddEF2WIVyM9XfPFlPxN5c6kaWYEClO5DntCqCvYr2ZbOtU7gzY0P/mTMKtWSPrE LIMR86RFUcgD0JK3qb4VcpdnTIhAp9Xh82r8C3WpIFQYEhp8I5wL2R3eWe4I8wZm pk5aCSLqllsR3jM+Y80LHfLKVMPey+mPTfQ2DW0lKmpKjL3ZSn6tSKE0SXlqM5sr MKqUuN/tgsV/fznLBFjrQEO8nVmr+UBwdeRggbt48HBFCRO/84Yw9L2fg9b470GO 9GLP2MbCXIISIvCMrRqOXI73Hg5IeEMxQPXknWFFhNDbzm5MlxT/zEClRogBoEcc D38d0TSh7KGJvLP6apOvku41J1Yz6n4a8g6mvEkdSzyx1lxoCD/nOaWLSONzrW/V Fj46ffREt9e220i/L2pPX0vEvllR7dBcpojCf8mNju7Y2yPS/GBgZGUARG2eUS/6 hc7Su7q5idJhlxEIFm4gMRipKLSARmY3G0q8MGZPUnXZm8XUQMPgeZUEj52Vyic4 xUjuLS7HbzDmT32JA5XotccofcyElf0J1hWCH/emUzbn23UqsrLGSiN0qWFzOe8+ pAovoZAsmfKKmUA66WQj =mDZ1 -END PGP SIGNATURE- Accepted: rocksndiamonds_3.3.0.1+dfsg1-2.2.debian.tar.gz to contrib/r/rocksndiamonds/rocksndiamonds_3.3.0.1+dfsg1-2.2.debian.tar.gz rocksndiamonds_3.3.0.1+dfsg1-2.2.dsc to contrib/r/rocksndiamonds/rocksndiamonds_3.3.0.1+dfsg1-2.2.dsc rocksndiamonds_3.3.0.1+dfsg1-2.2_amd64.deb to contrib/r/rocksndiamonds/rocksndiamonds_3.3.0.1+dfsg1-2.2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1svjy1-ly...@franck.debian.org
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
18.05.2012 00:11, Russ Allbery пишет: Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. As always, it's easier to add another abstraction layer and so generate the (somewhat pointless) source package and upload that, rather than modifying dak (and/or buildd) to handle two kinds of sources and source tools. I do agree it'd be better if we could just get rid of source packages, but we're far from there yet, sadly. Oh, sure. And I'd be fine with that. I just really like the idea of having everything about the package build automated, including generation of the source package, so that we no longer have problems where the maintainer does something weird on their local system. I'm fine with it being optional for those who want to use it, but I'd like to use it. One would test the build locally and then just push the tag, and the whole process would be reproduced in our infrastructure with a known configuration and we'd identify problems much faster. It would also mean that any Debian maintainer could easily clone the canonical source for a package that's using Git and that infrastructure, which we sort of have with debcheckout but a bit awkwardly, and NMUs could always be pushed to the same place, with the security handled via regular upload rights checking instead of the more ad hoc git.debian.org permission approach. It feels like the sort of direction in which software development is moving, and it feels like embracing our tools in ways that we're not yet doing. What about stable release? Git branches? What about users who want rebuild a package (probably with new patches)? dget functionality is really good for me. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb60a9e.5010...@gmail.com
Accepted open-axiom 1.4.1+svn~2626-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 16 May 2012 15:22:53 +0400 Source: open-axiom Binary: open-axiom open-axiom-source open-axiom-test open-axiom-databases open-axiom-tex open-axiom-graphics open-axiom-graphics-data open-axiom-hypertex open-axiom-hypertex-data Architecture: source amd64 all Version: 1.4.1+svn~2626-2 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: open-axiom - open scientific computation platform open-axiom-databases - open scientific computation platform: generated text databases open-axiom-graphics - open scientific computation platform: graphics subsystem open-axiom-graphics-data - open scientific computation platform: graphics subsystem data open-axiom-hypertex - open scientific computation platform: hypertex subsystem open-axiom-hypertex-data - open scientific computation platform: hypertex subsystem data open-axiom-source - open scientific computation platform: source files open-axiom-test - open scientific computation platform: regression test inputs open-axiom-tex - open scientific computation platform: style file for TeX Changes: open-axiom (1.4.1+svn~2626-2) unstable; urgency=low . * Added libgmp-dev build-dep for GCL Checksums-Sha1: fa8efb06bc067665e5a8029bdaa807888cce8ce5 2158 open-axiom_1.4.1+svn~2626-2.dsc ac1795b57cb83ccc0de680f537a7625e56241164 14261 open-axiom_1.4.1+svn~2626-2.debian.tar.gz daba9b7caf36db757884104e2a4f60a00ab4b15c 26047726 open-axiom_1.4.1+svn~2626-2_amd64.deb ca83f732390552f877efa51bf80f86f62a3e3877 1172450 open-axiom-source_1.4.1+svn~2626-2_all.deb 5177b14c638905f042e060d170f59a0e9770cbb4 201462 open-axiom-test_1.4.1+svn~2626-2_all.deb 56b64ae321a2f6450d856b46cad4e5a71795e600 1384866 open-axiom-databases_1.4.1+svn~2626-2_all.deb f3d26b0650023b35ae85ef2c93dfe4703720c7da 4828 open-axiom-tex_1.4.1+svn~2626-2_all.deb 2b2109a2108f260fc53087fe11cb979c4c1899b9 172530 open-axiom-graphics_1.4.1+svn~2626-2_amd64.deb 395350cdf6c1dc0644fed80932736a2c5cbbe177 7998 open-axiom-graphics-data_1.4.1+svn~2626-2_all.deb 4dd5c60dcbbf561e87a9f40c7a1159d894b33ce8 121638 open-axiom-hypertex_1.4.1+svn~2626-2_amd64.deb 5ac313d5b13db716685f7d42f7e0bbf2a1ff0d77 1476516 open-axiom-hypertex-data_1.4.1+svn~2626-2_all.deb Checksums-Sha256: bd7606ce49f1e65760c83072f5e866e3f15e341dbfc46d44aca090d1698c1940 2158 open-axiom_1.4.1+svn~2626-2.dsc d0da7a1575131085a010c1b356f537be46d699800145d4b1763d2545197e0d0a 14261 open-axiom_1.4.1+svn~2626-2.debian.tar.gz 18360865d570e9766282768c889f8bcbf61354c099c322fb92f817ab7084cdd9 26047726 open-axiom_1.4.1+svn~2626-2_amd64.deb 1078071635b23ff1f21269bd75c991e0c91359db2b5f2516383ad37dcbf2 1172450 open-axiom-source_1.4.1+svn~2626-2_all.deb 2372d4d81c5b873a24ebfa1463abc3df16895fa429e8f8664b6a66407081e5a3 201462 open-axiom-test_1.4.1+svn~2626-2_all.deb aa501ec5566a53459cc1413b5b70d2e9d38b33ac7159a5c5b443ca70df920d03 1384866 open-axiom-databases_1.4.1+svn~2626-2_all.deb 4a1917db6caa139914b400a4adff4aec6a2894b2f568507e419f95c32f159e54 4828 open-axiom-tex_1.4.1+svn~2626-2_all.deb b12260950d3c93a6ac481f1c42b28551af99e6b2ac357e81c278522de6cbdbc6 172530 open-axiom-graphics_1.4.1+svn~2626-2_amd64.deb 02d29397c8ac94c833813cbac5fa0dc0e0454eeec58ca5d9edac9b5a7ff6f92b 7998 open-axiom-graphics-data_1.4.1+svn~2626-2_all.deb 0e28ec7eac769bb03bdde0d7473b6c1ec3d43c06c798f633191ad04cce3ee987 121638 open-axiom-hypertex_1.4.1+svn~2626-2_amd64.deb d834276e601b013559639b5c5709cfc7c191bab5ae47b7734dae80cf87338066 1476516 open-axiom-hypertex-data_1.4.1+svn~2626-2_all.deb Files: a0ec684b47739453c335e18adf369952 2158 math optional open-axiom_1.4.1+svn~2626-2.dsc c6b6193758874279ea69f58acd06f5a1 14261 math optional open-axiom_1.4.1+svn~2626-2.debian.tar.gz 3fd98ea0742e88ab73c0588ac3ff203e 26047726 math optional open-axiom_1.4.1+svn~2626-2_amd64.deb 40690ee9c869a52ec95943d70dac187a 1172450 math optional open-axiom-source_1.4.1+svn~2626-2_all.deb a5c1ebead8e6de3be282e4f75a69148d 201462 math optional open-axiom-test_1.4.1+svn~2626-2_all.deb 853f6fc9b9f832dca83b5d0d5c64f1eb 1384866 math optional open-axiom-databases_1.4.1+svn~2626-2_all.deb 8045254f1e8c34b7d2907e41ac99f8b4 4828 math optional open-axiom-tex_1.4.1+svn~2626-2_all.deb 0ec84ab803dab9a5a60276d9272b4d60 172530 math optional open-axiom-graphics_1.4.1+svn~2626-2_amd64.deb 39d5f40e113287d7ccd53aacd302650c 7998 math optional open-axiom-graphics-data_1.4.1+svn~2626-2_all.deb 7127516c9a7cd9e5ff108c1e45d63eed 121638 math optional open-axiom-hypertex_1.4.1+svn~2626-2_amd64.deb d9de48d72d4dccc8c77f00b963604b34 1476516 math optional open-axiom-hypertex-data_1.4.1+svn~2626-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iJwEAQECAAYFAk+zn3wACgkQTiiN/0Um85kHnQQAuRvpF32PdkiAA88kHtfycaMe LiWAGF/8rhGfG1AqkBm2ZOKMtxSUH0qWsu2Bkf7fI5hM1sotR8+uuXt8IRdW/yGw G24kDZfxLbunGzFiVM8bIzpMZnz
Accepted open-axiom 1.4.1+svn~2626-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 10 May 2012 16:23:17 +0400 Source: open-axiom Binary: open-axiom open-axiom-source open-axiom-test open-axiom-databases open-axiom-tex open-axiom-graphics open-axiom-graphics-data open-axiom-hypertex open-axiom-hypertex-data Architecture: source amd64 all Version: 1.4.1+svn~2626-1 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: open-axiom - open scientific computation platform open-axiom-databases - open scientific computation platform: generated text databases open-axiom-graphics - open scientific computation platform: graphics subsystem open-axiom-graphics-data - open scientific computation platform: graphics subsystem data open-axiom-hypertex - open scientific computation platform: hypertex subsystem open-axiom-hypertex-data - open scientific computation platform: hypertex subsystem data open-axiom-source - open scientific computation platform: source files open-axiom-test - open scientific computation platform: regression test inputs open-axiom-tex - open scientific computation platform: style file for TeX Closes: 648877 Changes: open-axiom (1.4.1+svn~2626-1) unstable; urgency=low . * New upstream version * Include directory 'contrib' in sources * Removed patch for system xpm.h (fixed in upstream) * Use SBCL where available (currently i386, amd64, kfreebsd-amd64) and GCL otherwheres (Closes: #648877) * Bump standards version 3.9.2 → 3.9.3, no changes * Rewrote debian/rules (too many overrides) * Removed Encoding key from desktop file Checksums-Sha1: c4ba2e58fd1f797da710b706c9d3f2aad7ae3a19 2115 open-axiom_1.4.1+svn~2626-1.dsc 048698ee72f0bed5dbff513017c0392e9ffcf6d6 11615916 open-axiom_1.4.1+svn~2626.orig.tar.gz fb7ce815659abc1e25a610aa1c8b89c22e472105 14262 open-axiom_1.4.1+svn~2626-1.debian.tar.gz acff1811e29c82ce1eb0c3ee11a7882c46febbcb 26047524 open-axiom_1.4.1+svn~2626-1_amd64.deb bd7a70f33d346ab101f96e0c49aa0ebf7be0bf1b 1172434 open-axiom-source_1.4.1+svn~2626-1_all.deb 709096e95a75ba74482341be3082fdf8d56f8bb8 201420 open-axiom-test_1.4.1+svn~2626-1_all.deb 997c9102d2be22eb9b8f1328485f62cb4ccfee6c 1384788 open-axiom-databases_1.4.1+svn~2626-1_all.deb 7a8d907c266f8f5836d9bfb91a6c74364fba22f4 4786 open-axiom-tex_1.4.1+svn~2626-1_all.deb ba79b76e5addbf8087ed1d6685a81ea106c52054 172520 open-axiom-graphics_1.4.1+svn~2626-1_amd64.deb 09bcdb0f78c9d67f0d793bcc4c9a99f4bf28d4f2 7948 open-axiom-graphics-data_1.4.1+svn~2626-1_all.deb ac1cb107b0faf69c25b0fbc7b9a49b5528efab84 121642 open-axiom-hypertex_1.4.1+svn~2626-1_amd64.deb d7e7edca353b429040fb3c527c18a6df88f35fc0 1476490 open-axiom-hypertex-data_1.4.1+svn~2626-1_all.deb Checksums-Sha256: 71ee13d37b4665b89b7e4088e4fba77f849dcef01b305ecb9084698d3c5f4f1d 2115 open-axiom_1.4.1+svn~2626-1.dsc 43f30d002faed298ac920581e825103f8bd523d59ba2a4b0d5903a57abf2d2b4 11615916 open-axiom_1.4.1+svn~2626.orig.tar.gz 1d2737a81f88ac3134f1ee9de9cfc4b2830745d7566a12c538b28763ccd3ee35 14262 open-axiom_1.4.1+svn~2626-1.debian.tar.gz 359e9ad7e78d9266dc7535a282d327c1b4493a77b662b6289f1e1f6aae000e22 26047524 open-axiom_1.4.1+svn~2626-1_amd64.deb 46e105778dffef29b3322fe389f267b7bd7fe72c43c254c1baaafdc3af837176 1172434 open-axiom-source_1.4.1+svn~2626-1_all.deb 2483ad31a75d66a50bc4fb14635c03d0b2d3a8bc0c4ff2b8ea50eaa6daf4d2d1 201420 open-axiom-test_1.4.1+svn~2626-1_all.deb 7f4640ceb3e9ab14d52ef81f2f80ea94cae07cfed1577e23dc767a8ddc502402 1384788 open-axiom-databases_1.4.1+svn~2626-1_all.deb f1cbe6e062b6e5912d37fefbd703cef4b9ccf9dbdd3ba19c19540987dadc166c 4786 open-axiom-tex_1.4.1+svn~2626-1_all.deb 4504f8f18c1c18fd7f2095c53a4a406f9c2eae31aefedbcda0155e97b33c778b 172520 open-axiom-graphics_1.4.1+svn~2626-1_amd64.deb a27519e594e9498c9d120ffb643e82ba45e63839890c4b39ab6e42c86610c1e0 7948 open-axiom-graphics-data_1.4.1+svn~2626-1_all.deb 2ecde43e2bcc54979e6671889cb09d6c7547ef464a54bb09dd02f9b6dc95c812 121642 open-axiom-hypertex_1.4.1+svn~2626-1_amd64.deb 5751190c39e2611a191b49b9799ef1f048ebf1aca3a5ca42fc75510a4beb89da 1476490 open-axiom-hypertex-data_1.4.1+svn~2626-1_all.deb Files: fa84dc4ad75b12e3a855e22873c68cc6 2115 math optional open-axiom_1.4.1+svn~2626-1.dsc 51fad5fae95a75771fb68aa69f939fc3 11615916 math optional open-axiom_1.4.1+svn~2626.orig.tar.gz 91e62d7b775970ae4e8f9ac2a0935fed 14262 math optional open-axiom_1.4.1+svn~2626-1.debian.tar.gz df7b79a7a13fecb78562e90d6e42f57a 26047524 math optional open-axiom_1.4.1+svn~2626-1_amd64.deb 006e28df9108402fb6cd9bcae6cb75d8 1172434 math optional open-axiom-source_1.4.1+svn~2626-1_all.deb 8d048b27aa9ac1e7b7b8f909e4d5a955 201420 math optional open-axiom-test_1.4.1+svn~2626-1_all.deb 6154a3f396029de08f716c83b9aa12c4 1384788 math optional open-axiom-databases_1.4.1+svn~2626-1_all.deb f9f2fa9776866d3f3c7a303897f51110 4786 math optional open-axiom-tex_1.4.1+svn~2626-1_all.deb
Re: Licenses not in /usr/share/common-licenses
07.05.2012 14:33, Andrea Veri пишет: Hi, while packaging a few extensions (mainly licensed under the MPL) within the pkg-mozext team we received a few rejects from the FTP Team having the following rationale: the MPL license is not installed under /usr/share/common-licenses, thus the full text has to be added into debian/copyright. Since the MPL is not a short license [1], we decided to handle the current situation by linking the license to a static file included in the /usr/share/doc/xul-ext-packagename directory this way: License: MPL-1.1 The complete text of the Mozilla Public License can be found in the `MPL' file in the same directory as this file. We, then, received another reject. So, what's the working solution for these kind of cases? is it including the full text of the license a bit of a non-sense when we can directly link back to a static file? what's the rationale behind including the full license? why the relevant bug report [2] has been started back in 2008 but as of today, has still no decision? Thanks in advance, Andrea [1] http://www.mozilla.org/MPL/2.0/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487201 I think now it's the best to include full text into debian/copyright. Until (if ever) MPL included in base-files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fa7a7fc.8080...@gmail.com
Re: [Pkg-javascript-devel] Node.js and it's future in debian
+1 to let Node.js be just node -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9ea18a.8030...@gmail.com
Re: RFC: OpenRC as Init System for Debian
I wonder no one mention Solaris SMF :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f981885.2020...@gmail.com
Re: RFS: libblocxx/544~svn-1 (2nd try + updated pkg)
19.04.2012 12:30, Björn Esser пишет: Severity: wishlish *** UPDATE *** New version from svn trunk (544~svn replaces 2.1.0). Documentation (html + LaTeX) is now included in build-process. Dear mentors, I am looking for a sponsor for my package libblocxx. Have a look at it, please. * Package name: libblocxx Version : 544~svn-1 Upstream Author : (C) 2000-2009 Quest Software, Inc. (C) 2005-2006 Novell, Inc. All rights reserved. (C) 2000-2006 Vintela, Inc. All rights reserved. * URL : http://blocxx.sf.net/ * License : BSD-3 Section : libs It builds those binary packages: libblocxx-dbg - BloCxx debugging symbols libblocxx-dev - BloCxx development libraries and header files libblocxx-doc - BloCxx documentation and examples libblocxx8 - BloCxx - C++ Framework for Application Development To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libblocxx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libb/libblocxx/libblocxx_544~svn-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Initial release (Closes: #647639) * include documentation in build * add patch: use default automake * add patch: change BloCxx version to 544svn * add patch: fix path to dot in Doxyfile.in * add patch: exclude testsuite from documentation * add patch: don't build autogenerated manpages Regards, Björn Esser I'm not intended to support this package :-), but here are some issues I see: 1. Version in configure.in is 2.3.0, so debian package it should be 2.3.0~svn544 or 2.2.0+svn544 (make sure if 2.3 is ongoing release) 2. hello http://www.example.com :-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8fd122.4080...@gmail.com
Re: RFS: augeas/0.10.0-0.1 [NMU]
16.04.2012 15:37, Ansgar Burchardt пишет: Please do so first, for example by asking for the new version in the BTS. You can also include your proposed NMU diff if you want to help the maintainer. A NMU should only be done if the maintainer is busy and cannot react himself. I'll always contact maintainer first, I'll always contact maintainer first, I'll always contact maintainer first... ok, thank :-) Well, here is Nokolas: https://launchpad.net/~nvalcarcel he is not Canonical employeer, so email should be changed in any way (it is not valid: mails are rejected) I wrote to the uploaders too yesterday and CC now. Waiting for response. As for augeas I filled some upstream bugs and added more patches. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8d6a80.2070...@gmail.com
Re: RFS: augeas/0.10.0-0.1 [NMU]
17.04.2012 20:46, Nicolas Valcárcel пишет: Yes, i got contacted and i +1'd the upload, but i don't work for canonical anymore so my e-mail is not that one, so if you can please update my e-mail to nvalcar...@gmail.com that'll be great. Also about the -1 remove about naturaldocs you'll need to talk to raphael (CC'ing him) he was the one that did that changed and it depended on a specific version, not sure if the -1 is indeed needed. Other than that i'm ok with the upload. (I actually sent a RFS a while ago IIRC) Thanks for reply and sorry for rushing :-) Here is updated package: http://mentors.debian.net/package/augeas I've changed your email. There are some ohter issues (vim addons, standard version, splitting (#641842)), but it requires more thoughtful treatment. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8dcfc0.9000...@gmail.com
Re: RFS: augeas/0.10.0-0.1 [NMU]
16.04.2012 13:52, Ansgar Burchardt пишет: On 04/16/2012 11:20 AM, Игорь Пашев wrote: dget -x http://mentors.debian.net/debian/pool/main/a/augeas/augeas_0.10.0-0.1.dsc Changes since the last upload: augeas (0.10.0-0.1) unstable; urgency=low . * Non-maintainer upload * New upstream release * Updated symbols * Added upstream patch for sudoers (Closes: #650079) * Added upstream patch for debctl (Closes: #650887) * Added upstream patch for modprobe (Closes: #641813) * Closes: #602703, #510850, #648772 (fixed early in upstream) What do you mean by fixed early in upstream? I mean these bugs were fixed in previous versions (0.8, 0.9), but not mentioned in debian/changelog. I though never-fixed-bugs is worse than this changelog entry. * Fixed build-deps (build-depends-on-1-revision) ^^^ You also added a new build-dependency. Please mention that in the changelog, the current entry suggests you only removed the -1. Ok. Did you try to contact the package maintainers? No. I just needed newer version ASAP, so here it is, and at one I decided to review bugs and upload the new package. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8bf95e.9030...@gmail.com
Re: [oi-dev] New BE every package update?
It is a kind of intimation on stability and usability of IPS and userland *trollface* 15.04.2012 23:51, Milan Jurik пишет: Hi, is it expected with the latest prestable that new backup BE is created even if minor binary is updated? $ pfexec pkg install scantailor Packages to update: 1 Create boot environment: Ne Create backup boot environment: Ano [...] $ pkg contents scantailor PATH usr usr/bin usr/bin/scantailor usr/bin/scantailor-cli usr/share usr/share/scantailor usr/share/scantailor/translations usr/share/scantailor/translations/scantailor_bg.qm usr/share/scantailor/translations/scantailor_cs.qm usr/share/scantailor/translations/scantailor_de.qm usr/share/scantailor/translations/scantailor_es.qm usr/share/scantailor/translations/scantailor_fr.qm usr/share/scantailor/translations/scantailor_it.qm usr/share/scantailor/translations/scantailor_ja.qm usr/share/scantailor/translations/scantailor_pl.qm usr/share/scantailor/translations/scantailor_pt_BR.qm usr/share/scantailor/translations/scantailor_ru.qm usr/share/scantailor/translations/scantailor_sk.qm usr/share/scantailor/translations/scantailor_uk.qm usr/share/scantailor/translations/scantailor_zh_TW.qm $ beadm list BE Active Mountpoint Space Policy Created libhal - - 5,23G static 2012-03-27 20:46 nscd - - 675M static 2012-04-11 21:35 oi-install - - 18,0M static 2011-10-03 23:44 openindiana- - 18,9M static 2011-10-07 19:07 openindiana-5 - - 3,19G static 2012-02-17 20:51 openindiana-6 - - 29,0M static 2012-02-17 23:05 openindiana-7 NR / 29,4G static 2012-04-12 21:42 openindiana-7-backup-1 - - 6,32M static 2012-04-13 22:25 openindiana-7-backup-2 - - 220K static 2012-04-15 18:05 openindiana-7-backup-3 - - 215K static 2012-04-15 21:13 openindiana-7-backup-4 - - 225K static 2012-04-15 21:46 I was expecting BE snapshots through ZFS snapshots as it was. Not new BE. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Bug#661489: tagcoll2: portability fixes
Package: tagcoll2
Version: 2.0.11-1.1
Severity: wishlist
Dear Maintainer,
A have successfully compiled tagcoll2 on x86_64-pc-solaris2.11 by GCC 4.7 with
attached patches:
1. Solaris misses fmemopen()
2. Some OOP fixes
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: tagcoll2-2.0.13/tagcoll/tagexpr/Makefile.am
===
--- tagcoll2-2.0.13.orig/tagcoll/tagexpr/Makefile.am 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/tagexpr/Makefile.am 2012-02-28 02:24:56.187174567 +0400
@@ -10,6 +10,12 @@
TagexprParser.cc \
Tagexpr_parser_y.yy Tagexpr_parser_l.ll
+if NO_FMEMOPEN
+libtagexpr_la_SOURCES += \
+ fmemopen.c \
+ fmemopen.h
+endif
+
INCLUDES = -I$(top_srcdir) $(LIBWIBBLE_DEFS)
AM_YFLAGS = -d
Index: tagcoll2-2.0.13/tagcoll/tagexpr/fmemopen.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ tagcoll2-2.0.13/tagcoll/tagexpr/fmemopen.c 2012-02-28 02:08:29.003877978 +0400
@@ -0,0 +1,13 @@
+#include stdio.h
+
+FILE *fmemopen (void *buf, size_t size, const char *opentype)
+{
+FILE *f = NULL;
+if ((f = tmpfile()) != NULL) {
+fwrite(buf, 1, size, f);
+rewind(f);
+}
+return f;
+}
+
+
Index: tagcoll2-2.0.13/tagcoll/tagexpr/fmemopen.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ tagcoll2-2.0.13/tagcoll/tagexpr/fmemopen.h 2012-02-28 02:10:47.903965603 +0400
@@ -0,0 +1,17 @@
+#ifndef _FMEMOPEN_H
+#define _FMEMOPEN_H
+
+#include stdio.h
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+extern FILE *fmemopen(void *buf, size_t size, const char *mode);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _FMEMOPEN_H */
+
Index: tagcoll2-2.0.13/tagcoll/TextFormat-tut.cc
===
--- tagcoll2-2.0.13.orig/tagcoll/TextFormat-tut.cc 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/TextFormat-tut.cc 2012-02-28 02:14:45.381372438 +0400
@@ -24,6 +24,9 @@
#include tagcoll/stream/sink.h
#include tagcoll/patch.h
#include cstring
+#ifndef HAVE_FMEMOPEN
+#include tagcoll/tagexpr/fmemopen.h
+#endif
namespace tut {
using namespace std;
Index: tagcoll2-2.0.13/tagcoll/tagexpr/TagexprParser.cc
===
--- tagcoll2-2.0.13.orig/tagcoll/tagexpr/TagexprParser.cc 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/tagexpr/TagexprParser.cc 2012-02-28 02:14:44.146738957 +0400
@@ -26,6 +26,9 @@
#include wibble/exception.h
#include stdio.h
#include errno.h
+#ifndef HAVE_FMEMOPEN
+#include tagcoll/tagexpr/fmemopen.h
+#endif
// using namespace std;
using namespace wibble;
Index: tagcoll2-2.0.13/configure.ac
===
--- tagcoll2-2.0.13.orig/configure.ac 2011-09-01 20:37:05.0 +0400
+++ tagcoll2-2.0.13/configure.ac 2012-02-28 02:24:45.062179367 +0400
@@ -59,6 +59,9 @@
CXXFLAGS=$CXXFLAGS -Wall
+AC_CHECK_FUNC([fmemopen], [have_fmemopen=yes], [have_fmemopen=no])
+AM_CONDITIONAL([NO_FMEMOPEN], [test $have_fmemopen = 'no'])
+
AC_CONFIG_FILES([
Makefile
tagcoll/Makefile
Index: tagcoll2-2.0.13/tagcoll/patch.tcc
===
--- tagcoll2-2.0.13.orig/tagcoll/patch.tcc 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/patch.tcc 2012-02-28 02:32:50.135741040 +0400
@@ -53,7 +53,7 @@
iterator i = this-find(patch.item);
if (i == this-end())
- insert(make_pairITEM, PatchITEM, TAG (patch.item, patch));
+ this-insert(make_pairITEM, PatchITEM, TAG (patch.item, patch));
else
i-second.mergeWith(patch);
}
Index: tagcoll2-2.0.13/tagcoll/coll/fast.tcc
===
--- tagcoll2-2.0.13.orig/tagcoll/coll/fast.tcc 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/coll/fast.tcc 2012-02-28 02:33:57.686441329 +0400
@@ -240,7 +240,7 @@
templateclass ITEM, class TAG
std::setITEM FastITEM, TAG::getItemsExactMatch(const std::setTAG tags) const
{
- std::setITEM res = getItemsHavingTags(tags);
+ std::setITEM res = this-getItemsHavingTags(tags);
typename std::setITEM::iterator i = res.begin();
while (i != res.end())
{
Index: tagcoll2-2.0.13/tagcoll/Implications.h
===
--- tagcoll2-2.0.13.orig/tagcoll/Implications.h 2008-06-08 10:34:41.0 +0400
+++ tagcoll2-2.0.13/tagcoll/Implications.h 2012-02-28 02:34:31.870597436 +0400
@@ -107,7 +107,7 @@
typename std::setTAG implying = coll.getTagsImplying(*t);
for (typename
Bug#661225: libcairo-script-interpreter2: could be accidentally linked to binutils
Package: libcairo-script-interpreter2 Version: 1.10.2-6.2 Severity: minor Dear Maintainer, If package binutils-dev is installed, /usr/lib/cairo/libcairo-trace.so.0.0.0 will be linked to /usr/lib/libbfd-2.22-system.so from binutils. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcairo-script-interpreter2 depends on: ii libc6 2.13-26 ii libcairo2 1.10.2-6.2 ii libfontconfig1 2.8.0-3.1 ii libfreetype62.4.8-1 ii zlib1g 1:1.2.6.dfsg-2 libcairo-script-interpreter2 recommends no packages. libcairo-script-interpreter2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[oi-dev] How to name package with PAM module?
I'm creating a package with PAM module: file path=usr/lib/security/$(MACH64)/pam_sqlite.so file path=usr/lib/security/pam_sqlite.so What is a proper choice for FMRI of such a package? pkg:/library/pam/sqlite ? pkg:/security/pam/sqlite ? pkg:/library/pam-sqlite ? pkg:/security/pam-sqlite ? Or other? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How to name package with PAM module?
22.02.2012 17:16, Andrew Stormont пишет: I think what you want is pkg:/library/security/pam/module/pam-sqlite On 22/02/2012 13:10, Igor Pashevpashev.i...@gmail.com wrote: I'm creating a package with PAM module: file path=usr/lib/security/$(MACH64)/pam_sqlite.so file path=usr/lib/security/pam_sqlite.so What is a proper choice for FMRI of such a package? pkg:/library/pam/sqlite ? pkg:/security/pam/sqlite ? pkg:/library/pam-sqlite ? pkg:/security/pam-sqlite ? Or other? Well, thanks. And what about classification? Library/Security? ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: please test this code, if it is koscher
It's a troll. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f426f54.4070...@gmail.com
Accepted cuba 3.0+20111124-2 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 14 Feb 2012 11:23:40 +0400 Source: cuba Binary: libcuba3 libcuba3-dev cuba-partview libcuba3-dbg libcuba-doc Architecture: source amd64 all Version: 3.0+2024-2 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: cuba-partview - partition viewer for the Cuba library libcuba-doc - library for multidimensional numerical integration: documentation libcuba3 - library for multidimensional numerical integration libcuba3-dbg - library for multidimensional numerical integration: debug symbols libcuba3-dev - library for multidimensional numerical integration: development f Closes: 659154 Changes: cuba (3.0+2024-2) unstable; urgency=low . * Removed duplicate demo-c.out . cuba (3.0+2024-1) unstable; urgency=low . * New upstream release. * Link shared library with other libs. (Closes: #659154) Checksums-Sha1: c3e028721946f39573b7362bf0b415d1fc61d6c1 1298 cuba_3.0+2024-2.dsc 4a65dd84f0e5ae6395901ee0b5c6ebc73ae87e6c 354782 cuba_3.0+2024.orig.tar.gz e0e39fd167fbe15a2a703791d6593aa2a7804678 4745 cuba_3.0+2024-2.debian.tar.gz 819f1c95798826eefcc2cf054ef4cd724c22576b 278112 libcuba3_3.0+2024-2_amd64.deb 4ecdcd8dc72dca7c2bfc2fe7b9519161ce53 289578 libcuba3-dev_3.0+2024-2_amd64.deb 209c563207f0e0273ce2a55c2cbb5153a727c142 23948 cuba-partview_3.0+2024-2_amd64.deb bf716e566b8f729af54db8c4c313e2af3c4b69cb 278724 libcuba3-dbg_3.0+2024-2_amd64.deb 2d0921d44df349145a40708b38b51b3743edcb6e 211590 libcuba-doc_3.0+2024-2_all.deb Checksums-Sha256: ac284dcb841d84999814da3ada9291fdbc9ede4912eafaa11f412be412338ab5 1298 cuba_3.0+2024-2.dsc 547163bcc5a3264f1eeb6eeace7f6f0f7a30a944eaa2af22ef08d0b1d23e4dbb 354782 cuba_3.0+2024.orig.tar.gz 02d1c1472c66c777f2fd4f24bef7bb5b787772072372bf5ec84824f84b25a95d 4745 cuba_3.0+2024-2.debian.tar.gz aa2e15dff85968e5d0807978bb3611f62af8bc869f27c96e7cc4ac93a108207d 278112 libcuba3_3.0+2024-2_amd64.deb bf2ac6b8434f19ba13df36975b1412d1dc5421adc88a0e3f60f8ab000f7081ac 289578 libcuba3-dev_3.0+2024-2_amd64.deb dba3d19eb6f77fe841ff34cc13245928682ab71b72699f97c2c7d54a5f9866a6 23948 cuba-partview_3.0+2024-2_amd64.deb 6ad94099a042bfdf6015b6e347d9bf842eab04382fdbc81b037c545c681b81dd 278724 libcuba3-dbg_3.0+2024-2_amd64.deb 6bfc1ca7d0f8806c1f9d52e6c041601bbea41135e12acf83d2a2e78255c5a9e0 211590 libcuba-doc_3.0+2024-2_all.deb Files: f419f48f43bcb8f93788c30f865cb2d9 1298 math optional cuba_3.0+2024-2.dsc dfd4297a3d9c8ef439fd0f2fba531152 354782 math optional cuba_3.0+2024.orig.tar.gz 4424eb09b51464431a775ad0b8cd647e 4745 math optional cuba_3.0+2024-2.debian.tar.gz 0facd0d00fb207f4b0cf5f20175efe34 278112 math optional libcuba3_3.0+2024-2_amd64.deb 35d2061be9a7eb4cfff3d2ebac88c49e 289578 libdevel optional libcuba3-dev_3.0+2024-2_amd64.deb 3c8703a0429687c885cc42cefe8f2889 23948 math optional cuba-partview_3.0+2024-2_amd64.deb 6af204d326022af3575284bc53c2c5e6 278724 debug extra libcuba3-dbg_3.0+2024-2_amd64.deb b68106ae7c4bc6d81cc6405d911ebe6d 211590 doc optional libcuba-doc_3.0+2024-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk86pysACgkQoRg/jtECjI2ZVACfay5dYcAp9b1jx99JkHBPZ8sq YW0An0O+fXqhzkJkkyy7VT5baGfLwClS =UAwT -END PGP SIGNATURE- Accepted: cuba-partview_3.0+2024-2_amd64.deb to main/c/cuba/cuba-partview_3.0+2024-2_amd64.deb cuba_3.0+2024-2.debian.tar.gz to main/c/cuba/cuba_3.0+2024-2.debian.tar.gz cuba_3.0+2024-2.dsc to main/c/cuba/cuba_3.0+2024-2.dsc cuba_3.0+2024.orig.tar.gz to main/c/cuba/cuba_3.0+2024.orig.tar.gz libcuba-doc_3.0+2024-2_all.deb to main/c/cuba/libcuba-doc_3.0+2024-2_all.deb libcuba3-dbg_3.0+2024-2_amd64.deb to main/c/cuba/libcuba3-dbg_3.0+2024-2_amd64.deb libcuba3-dev_3.0+2024-2_amd64.deb to main/c/cuba/libcuba3-dev_3.0+2024-2_amd64.deb libcuba3_3.0+2024-2_amd64.deb to main/c/cuba/libcuba3_3.0+2024-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rxnal-0005nf...@franck.debian.org
Bug#653255: debian/rules.def: with_libssp is set to ' yes' (with space)
Package: gcc-4.7 Version: 4.7-20111222-1 Severity: normal with_libssp is set to ' yes' (with space), so comparation ifeq ($(with_libssp),yes) is always false. with_libssp is defined near line 862 in debian/rules.def: 862: $(shell if grep -qs '^\#define TARGET_LIBC_PROVIDES_SSP 1' $(builddir)/gcc/auto-host.h; then echo 'libc provides ssp'; else echo 'yes'; fi)) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653255: debian/rules.def: with_libssp is set to ' yes' (with space)
Package: gcc-4.7 Version: 4.7-20111222-1 Severity: normal with_libssp is set to ' yes' (with space), so comparation ifeq ($(with_libssp),yes) is always false. with_libssp is defined near line 862 in debian/rules.def: 862: $(shell if grep -qs '^\#define TARGET_LIBC_PROVIDES_SSP 1' $(builddir)/gcc/auto-host.h; then echo 'libc provides ssp'; else echo 'yes'; fi)) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111226004049.8413.66433.reportbug@moon
Bug#652174: pound control socket in wrong location
Package: pound Version: 2.5-1 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** pound 2.5-1 has config file /etc/pound/pound.cfg, which states control socket as /var/run/pound/poundctl.socket: 8 == # poundctl control socket Control /var/run/pound/poundctl.socket === 8 and directory /var/run/pound is not in package. There are two solutions: 1. put poundctl.socket into /run/ or 2. add /var/run/pound into package (with appropriate mode and owner) -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted cuba 3.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 17 Nov 2011 14:57:11 +0400 Source: cuba Binary: libcuba3 libcuba3-dev cuba-partview libcuba3-dbg libcuba-doc Architecture: source amd64 all Version: 3.0-1 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: cuba-partview - partition viewer for the Cuba library libcuba-doc - library for multidimensional numerical integration: documentation libcuba3 - library for multidimensional numerical integration libcuba3-dbg - library for multidimensional numerical integration: debug symbols libcuba3-dev - library for multidimensional numerical integration: development f Closes: 649076 Changes: cuba (3.0-1) unstable; urgency=low . * Initial release. (Closes: #649076) Checksums-Sha1: dfaba4c3adae9a04e68a82ed9851e6ff7f00ed8e 1235 cuba_3.0-1.dsc c04692005015c1e08dd078a696b83ee997ee4013 349838 cuba_3.0.orig.tar.gz c0a3ae365a18983a5564281af7919890fb7c0067 4629 cuba_3.0-1.debian.tar.gz 41669e5be8a7a3a1514d094308fba8f3b6a0cafc 273224 libcuba3_3.0-1_amd64.deb 1468ed546c59828e0324a9f46d0b6cc80f998fe5 285392 libcuba3-dev_3.0-1_amd64.deb c04344f378142de5e12c1c856eb777d03bcc140a 23718 cuba-partview_3.0-1_amd64.deb 5746d13eec26b01f53e746a047c1e8cc88a9b4d7 244460 libcuba3-dbg_3.0-1_amd64.deb b9c3421ca3b008312a993681a584b2f1f141c472 211322 libcuba-doc_3.0-1_all.deb Checksums-Sha256: 625cb5b4e2f836496e8603b3ec83a9faeeefa0a55ce4e64928304a09195642db 1235 cuba_3.0-1.dsc dfaf01e343526e7f355f1e85623e6b68b8916538a6b218e6b1a0198cfcf39155 349838 cuba_3.0.orig.tar.gz 169782e5635c1b2c67f1f4e52af744615f6771547663f78176992576ed843ee6 4629 cuba_3.0-1.debian.tar.gz 6a72c9059f6ed147b29bcd944698010f39c3db51638d1675479966d9cbdf915b 273224 libcuba3_3.0-1_amd64.deb ad5dacb6d2c841a5e4bdcde6546e5b49e3370c70f06f1836b15cec88250b57d9 285392 libcuba3-dev_3.0-1_amd64.deb fe47c277996b8fbd05c1a05946fa2595afbdadb0f5106f782c8d0066ebfdef5e 23718 cuba-partview_3.0-1_amd64.deb ab8f422e419ab56c8941e1d5abc6b0be7af5028d0867556425f95eebbcd4e721 244460 libcuba3-dbg_3.0-1_amd64.deb 2d55a2b3d32902c6b5905c5e4e31507b4a4bdadde9cb562266532f6a07aaaf99 211322 libcuba-doc_3.0-1_all.deb Files: e316a12c35fc808c5d9f235bb0f36189 1235 math optional cuba_3.0-1.dsc 56f508119f0ecb0d1d17c8b1df1453dd 349838 math optional cuba_3.0.orig.tar.gz 92268d23d5483bb87ebf25b540823add 4629 math optional cuba_3.0-1.debian.tar.gz ec85589df26834ede7e73d82b8782e86 273224 math optional libcuba3_3.0-1_amd64.deb 3ad6f5dc7e6bb26fddd9d57faf5d13d5 285392 libdevel optional libcuba3-dev_3.0-1_amd64.deb e55cfdebef4015648799154b3ee208a1 23718 math optional cuba-partview_3.0-1_amd64.deb cce96651ab63e5e83df52aa29480a4c7 244460 debug extra libcuba3-dbg_3.0-1_amd64.deb e4fc949e5d932b013aacddb135b88fdb 211322 doc optional libcuba-doc_3.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7mIuoACgkQoRg/jtECjI0uSwCfYbvPvFiUYUfLJdxLmkqICi7x +JEAn2NWgXGtmrEXKqdJSO1EENEw+DKT =Htj8 -END PGP SIGNATURE- Accepted: cuba-partview_3.0-1_amd64.deb to main/c/cuba/cuba-partview_3.0-1_amd64.deb cuba_3.0-1.debian.tar.gz to main/c/cuba/cuba_3.0-1.debian.tar.gz cuba_3.0-1.dsc to main/c/cuba/cuba_3.0-1.dsc cuba_3.0.orig.tar.gz to main/c/cuba/cuba_3.0.orig.tar.gz libcuba-doc_3.0-1_all.deb to main/c/cuba/libcuba-doc_3.0-1_all.deb libcuba3-dbg_3.0-1_amd64.deb to main/c/cuba/libcuba3-dbg_3.0-1_amd64.deb libcuba3-dev_3.0-1_amd64.deb to main/c/cuba/libcuba3-dev_3.0-1_amd64.deb libcuba3_3.0-1_amd64.deb to main/c/cuba/libcuba3_3.0-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1radij-00087x...@franck.debian.org
Re: Getting dh_install to do what we need
08.12.2011 13:49, Goswin von Brederlow пишет: Arno Tölldeb...@toell.net writes: Your own script-fu in debian/rules or external scripts isn't exactly the next best thing to read and learn how a foreign package works and there /are/ use cases where dh_install isn't flexible enough to deal with the problem by using the possibilities you had before. Renaming files and multi-arch support is what comes me in mind immediately. Yes, there are cases where dh_install isn't the tool you should or even can use. As for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632860 I ended with dh_movefiles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee098a4.50...@gmail.com
Re: Red Hat is moving from / to /usr/
08.12.2011 13:40, Goswin von Brederlow пишет: Igor Pashevpashev.i...@gmail.com writes: 07.12.2011 04:43, Marco d'Itri пишет: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf Discuss. I don't see any reason to move all into /usr from /, and make initrd for minimal system: Making self-contained initrd is the same problem as making self-contained / So why overhead? One problem for a minimal / is that there are so many different setups there, even more for Debian than for RH, and minimal has so many different meanings. Because of that more and more stuff has ended up in / over the years and it isn't quite so minimal anymore. The initramfs on the other hand is made to fit. So if /usr isn't on a networking filesystem (NFS) then you won't get networking stuff in the initramfs. No raid then mdadm isn't included. No lvm and the initramfs gets smaller again. And only select modules for one kernel are in there. Huge space saving again. So an initramfs will/can be minimal. The initramfs only needs to be self-contained for exactly one use case. The one where it is building on. The / needs to be self contained for every crazy setup any Debian user can think of. And initramfs is configurable by the admin. If something is missing he can add it. Properly fixing a not self-contained / on the other hand is difficult. So I don't agree that making a self-contained / is the same problem as making a self-contained initramfs. On the other hand initialy making initramfs support all the crazy things people do with /usr will be fun. Goswin, thanks for the explanation. Now I'm inclined to move all to /usr :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ee0c591.3040...@gmail.com
Re: Getting dh_install to do what we need
08.12.2011 18:49, Josselin Mouette пишет:
Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit :
,
| #! /usr/bin/dh_multiarchify
| /usr/lib/${DEB_HOST_MULTIARCH}/*
`
The /usr/bin/dh_multiarchify script
*tad*
It would need to be a compiled program, since you can’t use scripts in
shebangs.
(18:52:00)
[pashev@moon:~]
# cat shbang script
#!/bin/sh
echo $@
#!/home/pashev/shbang
dfwuefnwiuef
(18:52:06)
[pashev@moon:~]
# ./script
./script
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee0cf32.9090...@gmail.com
Re: Red Hat is moving from / to /usr/
07.12.2011 04:43, Marco d'Itri пишет: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf Discuss. I don't see any reason to move all into /usr from /, and make initrd for minimal system: Making self-contained initrd is the same problem as making self-contained / So why overhead? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edf4f21.7090...@gmail.com
Re: Detect if root login is disabled?
07.12.2011 12:53, Daniel Hartwig пишет: Hello I am looking at Bug#516854 and wondering: Is there a robust way for a *user* to detect if root login is disabled? Would like to perform such a check from an instance of aptitude running as a user account. I am aware of the following method which detects the `passwd -l' style lock, however, it requires read access to /etc/shadow: io:~# passwd -S root | grep L /dev/null; echo $? 1 io:~# passwd -l root passwd: password expiry information changed. io:~# passwd -S root | grep L /dev/null; echo $? 0 Thanks su? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4edf5114.50...@gmail.com
Re: Moving cron job from daily to weekly
02.12.2011 12:54, Tomasz Muras пишет: Hello, If a package installs cronjob in (say) /etc/cron.daily but administrator wants to move that into weekly job - would it be OK for him to simply move the configuration file from /etc/cron.daily to /etc/cron.weekly? Or do you think it may cause the problems for the package upgrade - and if so, what would be correct way to change the frequency of running packaged tool? Should I give any special considerations as a packager to handle this kind of situation? cheers, Tomek Maybe do not ship script in /etc/cron.*/ but keep it as example somewhere. And on fresh install copy in into /etc/cron.daily/, but on upgrade do nothing. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed89b7d.70...@gmail.com
Re: [oi-dev] gcc default
24.11.2011 11:22, Jorgen Lundman пишет: After figuring out the sfe repository stuff, we finally managed to install gcc-4. OpenIndiana runs nicely in 64bit, and everything is 64bit, including perl and perl modules. And yet, when you use gcc, the default output is 32bit. Does this really make sense any more? (on intel at least). Sure I can add -m64 to everything I compile, (presumably including perl modules) but is there no easy way to change the default from -m32 to -m64 ? I was stuffing around in the /usr/gcc/4.6/lib/gcc/i386-pc-solaris2.11/4.6.2/plugin/include/config/i386 area, but it appears to be used when compiling gcc. Not after. Should the default be changed to 64bit in the repository? Lund GCC = 4.7 will produce 64bit code by default on x86_64-solaris2.11 ;-) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Bug#649076: ITP: libcuba3 -- library for multidimensional numerical integration
Package: wnpp Severity: wishlist Owner: Igor Pashev pashev.i...@gmail.com * Package name: libcuba3 Version : 3.0 Upstream Author : Thomas Hahn h...@feynarts.de * URL : http://www.feynarts.de/cuba/ * License : LGPL Programming Lang: C Description : library for multidimensional numerical integration -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017104543.20987.22770.reportbug@moon
Bug#649076: ITP: libcuba3 -- library for multidimensional numerical integration
Package: wnpp Severity: wishlist Owner: Igor Pashev pashev.i...@gmail.com * Package name: libcuba3 Version : 3.0 Upstream Author : Thomas Hahn h...@feynarts.de * URL : http://www.feynarts.de/cuba/ * License : LGPL Programming Lang: C Description : library for multidimensional numerical integration -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649076: ITP: libcuba3 -- library for multidimensional numerical integration
Package: wnpp Severity: wishlist Owner: Igor Pashev pashev.i...@gmail.com * Package name: libcuba3 Version : 3.0 Upstream Author : Thomas Hahn h...@feynarts.de * URL : http://www.feynarts.de/cuba/ * License : LGPL Programming Lang: C Description : library for multidimensional numerical integration -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017104543.20987.22770.reportbug@moon
Bug#648877: open-axiom: Don't attempt to build on platforms without sbcl
Hi Michael! I'm preparing a new package which will use GCL where SBCL is unavailable. (GCL is recommended by upstream developer). 15.11.2011 23:51, Michael Terry пишет: Package: open-axiom Version: 1.4.1+svn~2299+ds-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu precise ubuntu-patch Dear Maintainer, sbcl is only available for i386 amd64 kfreebsd-amd64 kfreebsd-i386. Thus, open-axiom can't build on those platforms despite being declared as Architecture: any. It should use the same architecture line as sbcl. I've used the attached patch in Ubuntu; thank you for considering it. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise') Architecture: i386 (i686) Kernel: Linux 3.1.0-2-generic-pae (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
# ls -lh /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so lrwxrwxrwx 1 root root 35 Сен 17 08:41 /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so - /lib/x86_64-linux-gnu/libgcc_s.so.1 # ls -lh /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so lrwxrwxrwx 1 root root 35 Окт 10 22:41 /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so - /lib/x86_64-linux-gnu/libgcc_s.so.1 14.11.2011 13:43, Igor Kozhukhov пишет: Big problems - they are GCC_LIBS. We can't use different GCC version from /usr/gcc/version with GCC_LIBS from one place - because we have for example: libgcc_s.so.1 and others with the same names for different GCC versions and we have to use libgcc_s.so for -lgcc_s flags for linker. We don't have problems with tools if we are using static libs, but we have a big problems with dynamic libs - have to identify where primary libs is locate. We can put libs to different places, but it is next problem - we have to use RPATH for identification where libs locate - it is not good solution. Next problem - not critical, but present - we have package with GCC_LIBS and we have dependencies to this package in tools after builds. We have to re-build all tools after changing package name. Will be better to have ONE GCC version on the system and use it. This is example for GCC4.4 and GCC4.6 - not for GCC3 from /usr/sfw. -Igor On 11/13/11 2:06 AM, Richard Lowerichl...@richlowe.net wrote: On Sat, Nov 12, 2011 at 12:11, Igor Kozhukhovikozhuk...@gmail.com wrote: I think that link to /usr/bin/gcc - it as mistake, because you will broke illumos-gate build. The illumos build uses /usr/sfw/bin/gcc, If the build finds or tries to use /usr/bin/gcc, something is wrong with illumos. We have to save illumos-gate build based on current userland. That's why /usr/sfw/bin/gcc must be left alone /usr/bin/gcc should be fine. Of course, it's probably a good idea for someone to test that. The patched GCC4 is not important until the changes to illumos integrate. The intent behind the way we were structuring the GCC paths going forward was that the need for a special GCC for illumos does not impact any other use of GCC in the system. That is, /usr/gcc/X.Y.Z was to be used by people who _specifically_ required a version of GCC, such as illumos, whereas /usr/bin/gcc could be a convenient, user-appropriate, version. -- Rich ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
# dpkg -S libgcc_s lib32gcc1: /usr/lib32/libgcc_s.so.1 gcc-4.5: /usr/lib/gcc/x86_64-linux-gnu/4.5/libgcc_s.so libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 gcc-4.6: /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so 14.11.2011 14:16, Igor Kozhukhov пишет: They are libs for builds. What libs are using tools ? Ldd ? /usr/lib/libgcc_s.so.1 - ??? I know about using libs by GCC, but how to fix dependencies ? And how to fix tool for using another GCC libs ? I have problem what I said about GCC4. Changing location for libs - it is big problems for tools with RPATH. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
14.11.2011 15:12, Igor Kozhukhov пишет: I can see one real file: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 Try to guess what ldd will show ;-) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi-build feature #1252 - GCC 4.6.2
15.11.2011 05:04, Josef 'Jeff' Sipek пишет: On Mon, Nov 14, 2011 at 03:19:44PM +0400, Igor Pashev wrote: 14.11.2011 15:12, Igor Kozhukhov пишет: I can see one real file: libgcc1: /lib/x86_64-linux-gnu/libgcc_s.so.1 Try to guess what ldd will show ;-) Keep in mind that we have mediated links - something that debian doesn't have. It is not true, Debian has update-alternatives. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: Simplifying bootstrap on circular-dependent packages
Hi, In my humble experience I just used debian/shlibs.local :-) 05.11.2011 01:30, Daniel Ruoso пишет: I have been thinking about the bootstrapping of pakages lately. I am involved in bootstrapping a partial system -- no kernel and no libc -- for some architectures for internal use. And I just thought that we could use one trick to help in the bootstrap of packages that depend on other shared libraries, this is something we use internally for other reasons but I guess it could fit here as well. The basic idea is creating dummy libraries that would serve for the linking but that had no code on it. This would allow the linking to happen -- of course this only helps in the case where the build process doesn't run anything from the build-dependency. Later the other package in the cycle would be built, and the actual library would be made available instead of the dummy, and the linker would find the actual library. We already extract all that information for dpkg-shlibdeps to work, we could just build a fake shared library automatically based on that. What do you think? daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb9af83.4050...@gmail.com
Re: RFS: python-cpl
I think the name python-cpl is not descriptive enough 04.11.2011 00:07, Ole Streicher пишет: Dear mentors, I am looking for a sponsor for my package python-cpl. * Package name: python-cpl Version : 0.3.5-1 Upstream Author : Ole Streicher * URL : http://www.aip.de/~oles/python-cpl/index.html * License : GPL-2 Section : python It builds those binary packages: python-cpl - Control pipeline recipes from the European Southern Observatory To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-cpl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-cpl/python-cpl_0.3.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Ole Streicher P.S. This package requires the cpl package, http://mentors.debian.net/package/cpl -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb3a657.6070...@gmail.com
Re: RFS: python-cpl
CPL is too short for me, and is not widely known abbreviation, I guess. I just remember of Control Panel Library :-) CPL can stand for Crystallographic Protocol Library too Maybe python-eso-cpl, or python-eso.cpl, or python-esocpl. 04.11.2011 13:06, Ole Streicher пишет: Hi Igor, Igor Pashevpashev.i...@gmail.com writes: I think the name python-cpl is not descriptive enough what would you propose? I guess, the usual naming way for a python wrapper around a package foo is python-foo. Best regards Ole 04.11.2011 00:07, Ole Streicher пишет: Dear mentors, I am looking for a sponsor for my package python-cpl. * Package name: python-cpl Version : 0.3.5-1 Upstream Author : Ole Streicher * URL : http://www.aip.de/~oles/python-cpl/index.html * License : GPL-2 Section : python It builds those binary packages: python-cpl - Control pipeline recipes from the European Southern Observatory To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-cpl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-cpl/python-cpl_0.3.5-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Ole Streicher P.S. This package requires the cpl package, http://mentors.debian.net/package/cpl -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb45dbb.7080...@gmail.com
Re: directory under /usr/bin -- Ok or not?
03.11.2011 00:48, Roger Leigh пишет: When considering the divide between internal use and for users, consider that if it's for users to invoke then it should simply be in the default path. It's not typical to need to add special directories to one's path, and it's certainly not encouraged or recommended. Isn't /usr/libexec for internal use exetutables? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eb2e45e.1080...@gmail.com
Dependency on lib32foo vs libfoo on amd64
I'm building a package with: 64-bits app (foo), 64-bits lib (libfoo) and 32-bits lib (lib32foo). foo is linked with libfoo, but dependency in DEBIAN/control is set to li32foo. What's the matter? dpkg 1.16.1 DH 8.9.8 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9899bb.2090...@gmail.com
Re: Debian as Software Appliance
I believe there is no problem. One can run any software on top of Debian. Just be careful on non-Debian specific cases such as linking to GPL-only libs, etc. I strongly recommend Debian as a basis and as a demonstration of the power of free software ;-) 16.09.2011 00:39, zferentz пишет: Greetings, I'm not sure if this is the right place, so i hope that you can help me or point me to the right location . My company considering to ship our (commercial) product on top of a Linux software appliance . One of the suggestions was to use Linux Debian as a core . My questions are pretty basic : 1. can we simply create a software appliance and ship it to our customers ? we don't mind to provide the code for the free stuff , however we are not allowed to provide our own sources. 2. we plan to use LDAP and Apache , are there any restrictions that we shall be aware of ? 3. What if we're using the non-free repository ? can we ship stuff from there and publish the names of the packages ? Best regards, Zfe -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7274d1.6030...@gmail.com
Re: RFS: gentoo (New upstream version: package already in Debian).
13.09.2011 18:35, Marc Haber пишет: gentoo - Fully GUI-configurable, two-pane X file manager I would strongly suggest choosing a different name, due to the identically named Linux distribution. Gentoo is used as an example in Debian maintainer's guide :-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6f9c61.8000...@gmail.com
Re: Packaging php app/scripts
06.09.2011 00:44, kuLa пишет: Hi all, I have simple app in php and would like to package it. Source is in git (2 branches; upstream and debian, gbp.conf is pointing into these branches). I used dh_make to debianised package, relevant packages has been edited. When running git buildpackage final deb package is containing only docs in usr/share/doc/[package] dir (dh_installdocs i surnning as meant). When I'm trying to override_dh_install with dh_install --sourcedir=src I'm still having: cp: cannot stat `debian/tmp/src/index.php': No such file or directory My whole php app code is in src directory, so all files from this dir should be copied into package and they aren't. But package_1.0.0.orig.tar.gz created during build process is containing all files I need. Can anybody point me what should I change to achieve my goal? Thx for any help in advance. Would be nice if you show all files in ./debian (and its content) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e653d0c.5090...@gmail.com
Re: [open-axiom-devel] contrib/ licences
05.09.2011 04:30, Gabriel Dos Reis пишет: Hi Igor, The contrib/ directory is a collection of unrelated contributions. As such, each contribution tends to have its own license -- see contrib/README. When no explicit license file is present, the general license (BSD) governing OpenAxiom is assumed. Others, such as the texmacs interface has its own license (in the file texmacs/COPYING). I just in doublt: texmacs/COPYING is GPL-3, but files in texmacs are BSD or GPL-1. It is not clear what files are under GPL-3. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
Re: [open-axiom-devel] contrib/ licences
Ok, these files are under BSDL: texmacs/src/texbreaker.c, (by Robert S. Sutor) texmacs/src/userproto.h (by Robert S. Sutor I guess: it is used in texbreaker.c) Other files say about GNU general public license I thought it is version 1 by default :-) texmacs/Makefile refers to file LICENSE that is not present. 05.09.2011 15:05, Gabriel Dos Reis пишет: Igor Pashev pashev.i...@gmail.com writes: | 05.09.2011 04:30, Gabriel Dos Reis пишет: | | Hi Igor, | | The contrib/ directory is a collection of unrelated contributions. As | such, each contribution tends to have its own license -- see contrib/README. | When no explicit license file is present, the general license (BSD) | governing OpenAxiom is assumed. Others, such as the texmacs interface | has its own license (in the file texmacs/COPYING). | | I just in doublt: | | texmacs/COPYING is GPL-3, | but files in texmacs are BSD or GPL-1. hmm, which files are under GPL-1? The files under BSD are the ones who explicitly say so. | It is not clear what files are under GPL-3. I think all the files that come from vdHoeven are under GPL-3 -- at least the COPYING comes from there. Some also come from Bill Page. -- Gaby -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
Re: [open-axiom-devel] contrib/ licences
05.09.2011 15:42, Gabriel Dos Reis пишет: Igor Pashev pashev.i...@gmail.com writes: | Ok, these files are under BSDL: | texmacs/src/texbreaker.c, (by Robert S. Sutor) | texmacs/src/userproto.h (by Robert S. Sutor I guess: | it is used in texbreaker.c) | | Other files say about GNU general public license | I thought it is version 1 by default :-) | | texmacs/Makefile refers to file LICENSE | that is not present. Ah OK, COPYING should be LICENSE. -- Gaby I guess I will keep contrib in next packages :-) -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free Love Thy Logs t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
Re: RFS: open-axiom
03.09.2011 19:22, David Bremner пишет: On Sat, 03 Sep 2011 18:34:23 +0400, Igor Pashev pashev.i...@gmail.com wrote: Other architectures will be built on the autobuilder network, all going well. For the second question, it depends how long the package takes to pass through NEW. It is usually pretty quick these days, but it could be a week (or longer if the ftp-masters get busy). Hi, David. OA is in Sid now! And I have more questions: 1. Is it ok to use different lisps on different archs? Or is it better to wait for sbcl (in lenny there were many archs) ? 2. I set build-dep to sbcl = 1.0.30, but I see sbcl has an epoch. Should I change it? sbcl =2:1.0.30 (wheezy and sid have 2) ? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e633cd3.9070...@gmail.com
Re: RFS: open-axiom
Thank you David! I was blind: build-arch - binary-arch :-) Oh, and for next upload please add Vcs-Browser and Vcs-Git headers Is it ok to use github or whatsoever for this? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e63d953.5000...@gmail.com
Re: RFS: open-axiom
I have upload new version without ./contrib and ./src/include/xpm.h. The latter is going to be removed in upstream, that file is from very old Axiom version. ./contrib is not used now and has unclear license mess: ./contrib/texmacs/COPYING says about GPL-3, but sources are BSDL or GPL (1?). So, If unsure, say 'No' here ;-) http://mentors.debian.net/package/open-axiom -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e62188b.8020...@gmail.com
Re: RFS: open-axiom
Greate! Thank you. OA is uploaded to FTP. What about other architectures (i386, alpha, powerpc, etc)? Do I need another sponsor? :-) How much time does it take for package to appear in repo? 03.09.2011 16:37, David Bremner пишет: On Sat, 03 Sep 2011 16:07:39 +0400, Igor Pashev pashev.i...@gmail.com wrote: I have upload new version without ./contrib and ./src/include/xpm.h. The latter is going to be removed in upstream, that file is from very old Axiom version. ./contrib is not used now and has unclear license mess: ./contrib/texmacs/COPYING says about GPL-3, but sources are BSDL or GPL (1?). I guess that makes sense to me about contrib. It might be possible to fix by asking upstream for clarification what that COPYING file is meant to apply to. Removing xpm.h alone would not be a good reason to repack (although here, there is no real pristine upstream tarball), but since you are repacking anyway, OK. I'm rebuilding as we speak. By the way, parallel build support would be nice ;). d -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e623aef.90...@gmail.com
Accepted open-axiom 1.4.1+svn~2299+ds-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 03 Sep 2011 03:19:50 +0400 Source: open-axiom Binary: open-axiom open-axiom-source open-axiom-test open-axiom-databases open-axiom-tex open-axiom-graphics open-axiom-graphics-data open-axiom-hypertex open-axiom-hypertex-data Architecture: source amd64 all Version: 1.4.1+svn~2299+ds-1 Distribution: unstable Urgency: low Maintainer: Igor Pashev pashev.i...@gmail.com Changed-By: Igor Pashev pashev.i...@gmail.com Description: open-axiom - open scientific computation platform open-axiom-databases - open scientific computation platform: generated text databases open-axiom-graphics - open scientific computation platform: graphics subsystem open-axiom-graphics-data - open scientific computation platform: graphics subsystem open-axiom-hypertex - open scientific computation platform: hypertex subsystem open-axiom-hypertex-data - open scientific computation platform: hypertex subsystem open-axiom-source - open scientific computation platform: source files open-axiom-test - open scientific computation platform: regression test inputs open-axiom-tex - open scientific computation platform: style file for TeX Closes: 639185 Changes: open-axiom (1.4.1+svn~2299+ds-1) unstable; urgency=low . * Initial release. Closes: #639185 Checksums-Sha1: b1f53f685c281d80c5b9150601e5b218e5615cc6 1424 open-axiom_1.4.1+svn~2299+ds-1.dsc 1f0ad30deb45fc3ba8cf56180d0a11004b03cb7f 11844320 open-axiom_1.4.1+svn~2299+ds.orig.tar.gz ec929583a79b19976cc9fe8c635a9d1babc39f4b 13242 open-axiom_1.4.1+svn~2299+ds-1.debian.tar.gz 69c0c1a473b6cc95b66f79a647221b61695ffbaa 26769188 open-axiom_1.4.1+svn~2299+ds-1_amd64.deb 517fedd71fb75f17843858c5b174a205e276b5af 1285742 open-axiom-source_1.4.1+svn~2299+ds-1_all.deb 83e16f669f09ced15a11add84dce96646309b16a 201430 open-axiom-test_1.4.1+svn~2299+ds-1_all.deb 72410e5e396a00d30dee9187e52e9e6d4d69a326 1540382 open-axiom-databases_1.4.1+svn~2299+ds-1_all.deb 43b9642cb7a4d9b08183373cb862e315da93b868 4550 open-axiom-tex_1.4.1+svn~2299+ds-1_all.deb 7127967de2054c4ec578cb8a38da87f3d69212b9 172850 open-axiom-graphics_1.4.1+svn~2299+ds-1_amd64.deb c86150260be80b04f1f9fa0ff46201818d4e3108 7740 open-axiom-graphics-data_1.4.1+svn~2299+ds-1_all.deb 4d15ba18c3312aec9b969ed9ef79c6ffbebb4513 121636 open-axiom-hypertex_1.4.1+svn~2299+ds-1_amd64.deb 9e88b8acd8e52ddb28153715b91194b24b73da7d 1476260 open-axiom-hypertex-data_1.4.1+svn~2299+ds-1_all.deb Checksums-Sha256: c648fe52b22ef949d92356ddf6b11c66827710b67d8b8c9f2b95dcf76d6c2d21 1424 open-axiom_1.4.1+svn~2299+ds-1.dsc 8f7b505146619bd89d807b7660eb42aaa038c7bf5ea18eb6204b1ae734f651b8 11844320 open-axiom_1.4.1+svn~2299+ds.orig.tar.gz 6143d1dfb25e762dc32b26973aa98029cfeda3d8c7574210447d37ef3a8914c8 13242 open-axiom_1.4.1+svn~2299+ds-1.debian.tar.gz 4df5cc6c218bb970e2db47fe8acd7c6a16a44716713f55b49471ab50771a295e 26769188 open-axiom_1.4.1+svn~2299+ds-1_amd64.deb efad8f302056c725ad4481bec1c8cbfa5135e958b4859223e082db290d7a4571 1285742 open-axiom-source_1.4.1+svn~2299+ds-1_all.deb 53f728e64dd0b92dbd91e150c82d1835c4aa65ed48b5786a9c2b0562d71552bc 201430 open-axiom-test_1.4.1+svn~2299+ds-1_all.deb a5879b9baeaf024712a19024c332ae00ee345c07ddc9f6d3a3041eb862f495a0 1540382 open-axiom-databases_1.4.1+svn~2299+ds-1_all.deb 5c22ca3355046e52ea3a264b2a27b71fde49b02c8e8139b003a536b6e0cda653 4550 open-axiom-tex_1.4.1+svn~2299+ds-1_all.deb a34e711746ee82bf1520df9be903c0d078553d1076003e6805665b51abd95789 172850 open-axiom-graphics_1.4.1+svn~2299+ds-1_amd64.deb 95b51e7b4775f772607407fcfbdd7ff86afc0197ccd722953590594f2c64 7740 open-axiom-graphics-data_1.4.1+svn~2299+ds-1_all.deb 38f24fe10ad8a3b988e606be6645a4e57a20eecf6ad342dc9e7cea4994ccaa26 121636 open-axiom-hypertex_1.4.1+svn~2299+ds-1_amd64.deb 703aa54980564fc533325fd83b6495cc9f17d3a501582522d91bc1b6f9f199c3 1476260 open-axiom-hypertex-data_1.4.1+svn~2299+ds-1_all.deb Files: f0c9dc66ad85c19ff3a595c32b3f1e8a 1424 math optional open-axiom_1.4.1+svn~2299+ds-1.dsc ac13fddb651d4e29d23671d739065f3a 11844320 math optional open-axiom_1.4.1+svn~2299+ds.orig.tar.gz 57105edfe2b53ab3a16879ddc61e1456 13242 math optional open-axiom_1.4.1+svn~2299+ds-1.debian.tar.gz cb1c1eee8eb3ace1d610751cb894b493 26769188 math optional open-axiom_1.4.1+svn~2299+ds-1_amd64.deb 96faa9be054cb9a7d7e11092da3843ac 1285742 math optional open-axiom-source_1.4.1+svn~2299+ds-1_all.deb e2481d6ca9a20c65d6942820e33059b5 201430 math optional open-axiom-test_1.4.1+svn~2299+ds-1_all.deb 50d41319c52d201e2056075ec03ad8c4 1540382 math optional open-axiom-databases_1.4.1+svn~2299+ds-1_all.deb f47988ef500fbed68af20c576545964e 4550 math optional open-axiom-tex_1.4.1+svn~2299+ds-1_all.deb 4454c76145d9852ef2109adcd2c148ca 172850 math optional open-axiom-graphics_1.4.1+svn~2299+ds-1_amd64.deb 4945cc5c449b53c76cc61787ec1feccc 7740 math optional open-axiom-graphics-data_1.4.1+svn~2299+ds-1_all.deb e90e3507a8a18377338215ddfe621ebf 121636
[open-axiom-devel] error: 'struct OpenAxiom::Memory::Storage' has no member named 'at_offset'
Recent changes to src/utils/storage.H
prevent OA from building.
'at_offset' is mentioned twice in src/utils/storage.H:
= 8 =
211 // The `previous' link in the chain of storage.
212 static Storage* previous(Storage* s) {
213 return *static_castStorage**(s-at_offset(0));
214 }
215
216 // The `next' link in the chain of storage.
217 static Storage* next(Storage* s) {
218 return *static_castStorage**(s-at_offset(link_size));
219 }
8
cd utils make all-utils
make[2]: Entering directory
`/home/pashev/tmp/open-axiom.trunk/build-tree/src/utils'
../../libtool --tag=CXX --mode=compile g++ -c -m64 -D_GNU_SOURCE -g -O2
-O2 -Wall -I. -I../../x86_64-unknown-linux-gnu/include -I../../config
-I../../../src/include
-DOPENAXIOM_ROOT_DIRECTORY=\/usr/local/lib/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2011-09-03\
-o storage.lo ../../../src/utils/storage.cc
libtool: compile: g++ -c -m64 -D_GNU_SOURCE -g -O2 -O2 -Wall -I.
-I../../x86_64-unknown-linux-gnu/include -I../../config
-I../../../src/include
-DOPENAXIOM_ROOT_DIRECTORY=\/usr/local/lib/open-axiom/x86_64-unknown-linux-gnu/1.5.0-2011-09-03\
../../../src/utils/storage.cc -fPIC -DPIC -o .libs/storage.o
In file included from ../../../src/utils/storage.cc:59:0:
../../x86_64-unknown-linux-gnu/include/open-axiom/storage: In static
member function 'static OpenAxiom::Memory::Storage*
OpenAxiom::Memory::ArenaT::previous(OpenAxiom::Memory::Storage*)':
../../x86_64-unknown-linux-gnu/include/open-axiom/storage:213:47: error:
'struct OpenAxiom::Memory::Storage' has no member named 'at_offset'
../../x86_64-unknown-linux-gnu/include/open-axiom/storage: In static
member function 'static OpenAxiom::Memory::Storage*
OpenAxiom::Memory::ArenaT::next(OpenAxiom::Memory::Storage*)':
../../x86_64-unknown-linux-gnu/include/open-axiom/storage:218:47: error:
'struct OpenAxiom::Memory::Storage' has no member named 'at_offset'
../../x86_64-unknown-linux-gnu/include/open-axiom/storage: At global scope:
../../x86_64-unknown-linux-gnu/include/open-axiom/storage:290:10: error:
'iterator' does not name a type
../../x86_64-unknown-linux-gnu/include/open-axiom/storage:297:10: error:
'iterator' does not name a type
../../x86_64-unknown-linux-gnu/include/open-axiom/storage:346:26: error:
invalid class name in declaration of 'class
OpenAxiom::Memory::FactoryT::iterator'
make[2]: *** [storage.lo] Error 1
make[2]: Leaving directory
`/home/pashev/tmp/open-axiom.trunk/build-tree/src/utils'
make[1]: *** [all-utils] Error 2
make[1]: Leaving directory
`/home/pashev/tmp/open-axiom.trunk/build-tree/src'
make: *** [all-local] Error 2
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free Love Thy Logs t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
Re: RFS: open-axiom
30.08.2011 16:03, David Bremner пишет: On startup, I get (HyperDoc) read_ht_db: No ht.db file found. before the rest of the startup messages. Weirdly, the basic help commands I tried seemed to work, but I don't really know what to expect. I saw this message after making symlink /usr/lib/open-axiom/share/hypertex - /usr/share/open-axiom/hypertex And can't reproduce it after purging old version and clean install of new version. I guess, you have *upgraded* previous packages with new ones? I don't know why directory /usr/lib/open-axiom/share/hypertex keeped on upgrade. Please, check whether /usr/lib/open-axiom/share/hypertex is a symlink: # ls -lh /usr/lib/open-axiom/share/hypertex lrwxrwxrwx 1 root root 34 Авг 29 16:17 /usr/lib/open-axiom/share/hypertex - ../../../share/open-axiom/hypertex If not - purge old packages: apt-get purge open-axiom\* and install new. ht.db is actually present: # ls -lh /usr/lib/open-axiom/share/hypertex/pages/ht.db -rw-r--r-- 1 root root 396K Авг 29 15:57 /usr/lib/open-axiom/share/hypertex/pages/ht.db -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5cd4da.7030...@gmail.com
Re: RFS: open-axiom
- The second paragraph of the long description is not helpful to the debian user trying to decide whether to install the package; we try not to waste space in the description because it is stored in many places (e.g. /var/lib/dpkg/available). You are welcome to add a README.Debian file if you want to say more about the project. Removed the second paragraph. - rather than putting TODO in debian/control, it is better have a seperate TODO file that will be installed by dh_installdocs Added debian/TODO, cleaned debian/control. - In your debian/copyright file, you should mention the license for your packaging. It would be a good idea to have a seperate header line for license and to explicitly say by each copyright holder (NAG, Axiom Team) what license applies (do they all use the BSD-like mentioning NAG, or are there variants?). Mentioned copyright for debian/* Made OA copyright notice more clear, I think. - I'm confused why debian/open-axiom.png is listed in debian/source/include-binaries, but not include in the source package. Previous experiment? Yep, removed debian/source/include-binaries - Don't think removing the compiled from lines is needed, but it is your call. The shebang lines I agree should go. FASL-files are compiled from intermediate (produced from *.spad) lisp code, so references to this code does not make substantial sense. Also these line can disclose paths on a build machine. - at some point you should consider adding some metadata to your patches. I typically just use git-format-patch, but if using straight quilt you may want to look at http://dep.debian.net/deps/dep3/. Sure, but now all patches are quite obvious. So, I have uploaded new version with corrections you suggested. Please review it. Thanks for your efforts :-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5ba384.2000...@gmail.com
Re: RFS: open-axiom
28.08.2011 19:00, David Bremner пишет: I'm not sure if open-axiom uses this feature (and I notice sbcl itself also has broken #! lines in it's fasl files. In your case, I suspect the upstream build process is putting the wrong path into the #! lines. interpsys isn't installed by debian sbcl and it isn't included in the open-axiom source package. interpsys is a main tool to build OpenAxiom, it is not requred to run OA. One can think of it as of libtool or similar. Fasl-files are not used as scripts, but as modules (example below) I tried to change shebangs (keeping #!, of cause) - any little change confuses SBCL core. I wiil investigate more, though. AFAIK, fasl-files is binary compatible only with the exact SBCL version it was generated with (http://www.sbcl.org/manual/FASL-Format.html). Not sure whether they are arch-independent. (AO includes SBCL core, so SBCL itself is not required to run AO. And there is no problem to upgrade system SBCL :-) So, I guess I have to resolve two issues: 1. SBCL shebangs (I don't like it actually) 2. Location of HyperTex data (maybe symlink for a while). == Example of module usage == OpenAxiom: The Open Scientific Computation Platform Version: OpenAxiom 1.5.0-2011-07-07 Built on Sunday August 28, 2011 at 02:20:26 - Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave OpenAxiom and return to shell. - (1) - )set messages autoload on (1) - factor(x^3-x+2) Loading /usr/lib/open-axiom/algebra/UPMP.fasl for package UnivariatePolynomialMultiplicationPackage Loading /usr/lib/open-axiom/algebra/PAIR.fasl for domain Pair Loading /usr/lib/open-axiom/algebra/MULTFACT.fasl for package MultivariateFactorize Loading /usr/lib/open-axiom/algebra/COMPLEX.fasl for domain Complex Loading /usr/lib/open-axiom/algebra/INNMFACT.fasl for package InnerMultFact Loading /usr/lib/open-axiom/algebra/OAGROUP-.fasl for domain OrderedAbelianGroup Loading /usr/lib/open-axiom/algebra/OAMON-.fasl for domain OrderedAbelianMonoid Loading /usr/lib/open-axiom/algebra/MULTSQFR.fasl for package MultivariateSquareFree Loading /usr/lib/open-axiom/algebra/UPSQFREE.fasl for package UnivariatePolynomialSquareFree Loading /usr/lib/open-axiom/algebra/HEUGCD.fasl for package HeuGcd Loading /usr/lib/open-axiom/algebra/INMODGCD.fasl for package InnerModularGcd Loading /usr/lib/open-axiom/algebra/EMR.fasl for domain EuclideanModularRing Loading /usr/lib/open-axiom/algebra/MDDFACT.fasl for package ModularDistinctDegreeFactorizer Loading /usr/lib/open-axiom/algebra/MODRING.fasl for domain ModularRing Loading /usr/lib/open-axiom/algebra/ORDTYPE-.fasl for domain OrderedType Loading /usr/lib/open-axiom/algebra/BASTYPE-.fasl for domain BasicType Loading /usr/lib/open-axiom/algebra/DIFFSPC-.fasl for domain DifferentialSpace Loading /usr/lib/open-axiom/algebra/DIFFDOM-.fasl for domain DifferentialDomain Loading /usr/lib/open-axiom/algebra/PGCD.fasl for package PolynomialGcdPackage Loading /usr/lib/open-axiom/algebra/DSEXT-.fasl for domain DifferentialSpaceExtension Loading /usr/lib/open-axiom/algebra/FRETRCT-.fasl for domain FullyRetractableTo Loading /usr/lib/open-axiom/algebra/PDSPC-.fasl for domain PartialDifferentialSpace Loading /usr/lib/open-axiom/algebra/EVALAB-.fasl for domain Evalable Loading /usr/lib/open-axiom/algebra/PDDOM-.fasl for domain PartialDifferentialDomain Loading /usr/lib/open-axiom/algebra/GENUFACT.fasl for package GenUFactorize Loading /usr/lib/open-axiom/algebra/GALFACT.fasl for package GaloisGroupFactorizer Loading /usr/lib/open-axiom/algebra/FSAGG-.fasl for domain FiniteSetAggregate Loading /usr/lib/open-axiom/algebra/FLASORT.fasl for package FiniteLinearAggregateSort Loading /usr/lib/open-axiom/algebra/DIAGG-.fasl for domain Dictionary Loading /usr/lib/open-axiom/algebra/DIOPS-.fasl for domain DictionaryOperations Loading /usr/lib/open-axiom/algebra/SETAGG-.fasl for domain SetAggregate Loading /usr/lib/open-axiom/algebra/BGAGG-.fasl for domain BagAggregate Loading /usr/lib/open-axiom/algebra/BRILL.fasl for package BrillhartTests Loading /usr/lib/open-axiom/algebra/FLOAT.fasl for domain Float Loading /usr/lib/open-axiom/algebra/GALFACTU.fasl for package GaloisGroupFactorizationUtilities Loading /usr/lib/open-axiom/algebra/FPS-.fasl for domain FloatingPointSystem Loading /usr/lib/open-axiom/algebra/RNS-.fasl for domain RealNumberSystem Loading /usr/lib/open-axiom/algebra/TRANFUN-.fasl for
Bug#639185: ITP: open-axiom -- open scientific computation platform
Package: wnpp Severity: wishlist Owner: Igor Pashev pashev.i...@gmail.com * Package name: open-axiom Version : 1.4.1+svn~2299 Upstream Author : Gabriel Dos Reis g...@cs.tamu.edu * URL : http://www.open-axiom.org/ * License : Modified BSD Programming Lang: Boot, C++, CommonLisp Description : open scientific computation platform -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110824200850.15415.58146.reportbug@localhost
Bug#639185: ITP: open-axiom -- open scientific computation platform
Package: wnpp Severity: wishlist Owner: Igor Pashev pashev.i...@gmail.com * Package name: open-axiom Version : 1.4.1+svn~2299 Upstream Author : Gabriel Dos Reis g...@cs.tamu.edu * URL : http://www.open-axiom.org/ * License : Modified BSD Programming Lang: Boot, C++, CommonLisp Description : open scientific computation platform -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
