Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
On October 25, 2021 8:58:57 PM UTC, Luca Boccassi wrote: >On Mon, 2021-10-25 at 22:28 +0200, Domenico Andreoli wrote: >> Hi Adam, Luca and Theodore, >> >> On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote: >> > Package: sponsorship-requests >> > Severity: normal >> > >> > Dear all, >> > >> > I'm looking for a sponsor for this package: >> >> Could any of you please review this upload? >> >> Thanks! >> Dom > >Looks good to me, uploaded. Thanks! >Just a minor thing for the next time you prepare an upload: the build- >dep on libbpf-dev needs to be bumped, this version requires >= 0.4. I'll fix with the next upload. Thank you. Dom rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
Hi Adam, Luca and Theodore, On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote: > Package: sponsorship-requests > Severity: normal > > Dear all, > > I'm looking for a sponsor for this package: Could any of you please review this upload? Thanks! Dom > > * Package name: dwarves > Version : 1.22-1 > Upstream Author : Arnaldo Carvalho de Melo > * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git > * License : GPLv2 > Section : utils > > It builds these binary packages: > > dwarves - set of advanced DWARF utilities - transitional package > pahole- set of advanced DWARF utilities > pahole-dbgsym - debug symbols for pahole > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/dwarves > > Alternatively, you can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/dwarves/dwarves_1.22-1.dsc > > More information can be obtained from > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ > > Changes since the last upload: > > dwarves (1.22-1) unstable; urgency=low > > * New upstream release. > Changes since 1.20: > > pahole: > - Allow encoding BTF to a separate BTF file (detached) instead of to a new > ".BTF" ELF section in the file being encoded (vmlinux usually). > - Introduce -j/--jobs option to specify the number of threads to > use. Without arguments means one thread per CPU. So far used for > the DWARF loader, will be used as well for the BTF encoder. > - Show all different types with the same name, not just the first one > found. > - Introduce sorted type output (--sort), needed with multithreaded > DWARF loading, to use with things like 'btfdiff' that expects > the output from DWARF and BTF types to be comparable using 'diff'. > - Stop assuming that reading from stdin means pretty printing as this > broke > pre-existing scripts, introduce a explicit --prettify command line > option. > - Improve type resolution for the --header command line option. > - Disable incomplete CTF encoder, this needs to be done using the external > libctf library. > - Do not consider the ftrace filter when encoding BTF for kernel > functions. > - Add --kabi_prefix to avoid deduplication woes when using > _RH_KABI_REPLACE() > - Add --with_flexible_array to show just types with flexible arrays. > > DWARF Loader: > - Multithreaded loading, requires elfutils >= 0.178. > - Lock calls to non-thread safe elfutils' libdw functions > (dwarf_decl_file() > and dwarf_decl_line()) > - Change hash table size to one that performs better with current typical > vmlinux files. > - Allow tweaking the hash table size from the command line. > - Stop allocating memory for strings obtained from libdw, just defer > freeing > the Dwfl handler so that references to its strings can be safely kept. > - Use a frontend cache for the latest lookup result. > - Allow ignoring some DWARF tags when loading for encoding > BTF, as BTF doesn't have equivalents for things like > DW_TAG_inline_expansion and DW_TAG_label. > - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, > not used when encoding BTF. > - Do not query for non-C attributes when loading a C language CU > (compilation unit). > > BTF encoder: > - Preparatory work for multithreaded encoding, the focus for 1.23. > > btfdiff: > - Support diffing against a detached BTF file, > e.g.: 'btfdiff vmlinux vmlinux.btf' > - Support multithreaded DWARF loading, using the new pahole --sort > option to have the output from both BTF and DWARF sorted and thus > comparable via 'diff'. > > Build: > - Support building with libc libraries lacking either obstacks or argp, > such > as Alpine Linux's musl libc. > - Support systems without getconf() to obtain the data cacheline size, > such > as musl libc. > - Add a buildcmd.sh for test builds, tested using the same set of > containers > used for testing the Linux kernel perf tools. > - Enable selecting building with a shared libdwarves library or > statically. > - Allow one to use the libbpf package found in distributions instead > of with the accompanying libbpf git submodule. > > Cleanups: > - Address lots of compiler warnings accumulated by not using -Wextra, > it'll >
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves Version : 1.22-1 Upstream Author : Arnaldo Carvalho de Melo * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities - transitional package pahole- set of advanced DWARF utilities pahole-dbgsym - debug symbols for pahole To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves/dwarves_1.22-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves (1.22-1) unstable; urgency=low * New upstream release. Changes since 1.20: pahole: - Allow encoding BTF to a separate BTF file (detached) instead of to a new ".BTF" ELF section in the file being encoded (vmlinux usually). - Introduce -j/--jobs option to specify the number of threads to use. Without arguments means one thread per CPU. So far used for the DWARF loader, will be used as well for the BTF encoder. - Show all different types with the same name, not just the first one found. - Introduce sorted type output (--sort), needed with multithreaded DWARF loading, to use with things like 'btfdiff' that expects the output from DWARF and BTF types to be comparable using 'diff'. - Stop assuming that reading from stdin means pretty printing as this broke pre-existing scripts, introduce a explicit --prettify command line option. - Improve type resolution for the --header command line option. - Disable incomplete CTF encoder, this needs to be done using the external libctf library. - Do not consider the ftrace filter when encoding BTF for kernel functions. - Add --kabi_prefix to avoid deduplication woes when using _RH_KABI_REPLACE() - Add --with_flexible_array to show just types with flexible arrays. DWARF Loader: - Multithreaded loading, requires elfutils >= 0.178. - Lock calls to non-thread safe elfutils' libdw functions (dwarf_decl_file() and dwarf_decl_line()) - Change hash table size to one that performs better with current typical vmlinux files. - Allow tweaking the hash table size from the command line. - Stop allocating memory for strings obtained from libdw, just defer freeing the Dwfl handler so that references to its strings can be safely kept. - Use a frontend cache for the latest lookup result. - Allow ignoring some DWARF tags when loading for encoding BTF, as BTF doesn't have equivalents for things like DW_TAG_inline_expansion and DW_TAG_label. - Allow ignoring some DWARF tag attributes, such as DW_AT_alignment, not used when encoding BTF. - Do not query for non-C attributes when loading a C language CU (compilation unit). BTF encoder: - Preparatory work for multithreaded encoding, the focus for 1.23. btfdiff: - Support diffing against a detached BTF file, e.g.: 'btfdiff vmlinux vmlinux.btf' - Support multithreaded DWARF loading, using the new pahole --sort option to have the output from both BTF and DWARF sorted and thus comparable via 'diff'. Build: - Support building with libc libraries lacking either obstacks or argp, such as Alpine Linux's musl libc. - Support systems without getconf() to obtain the data cacheline size, such as musl libc. - Add a buildcmd.sh for test builds, tested using the same set of containers used for testing the Linux kernel perf tools. - Enable selecting building with a shared libdwarves library or statically. - Allow one to use the libbpf package found in distributions instead of with the accompanying libbpf git submodule. Cleanups: - Address lots of compiler warnings accumulated by not using -Wextra, it'll be added in the next release after allowing not to use it to build libbpf. - Address covscan report issues. Documentation: - Improve the --nr_methods/-m pahole man page entry. - Clarify that currently --nr_methods doesn't work together witn -C. * Refresh patches. * Drop patch no_shared_no_ebl, can do without it. * Build-Depends on linux-libc-dev (>= 5.14) for BTF_KIND_FLOAT. * Rename source package to dwarves. Closes: #705969. * Rename binary package to pahole and add a transitional dummy package. * Patch pahole manpage to fix groff's warning. * Configure gbp to sign tags by default. * Remove superfluous file patterns from debian/copyright. -- Domenico Andreoli Tue, 19 Oct 2021 23:31:2
Bug#979155: RFS: dwarves-dfsg/1.18-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.18-1 Upstream Author : Arnaldo Carvalho de Melo * URL : https://git.kernel.org/pub/scm/devel/pahole/pahole.git * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.18-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.18-1) unstable; urgency=medium [ Domenico Andreoli ] * New upstream release (changes since 1.17): - Use type information to pretty print raw data from stdin, all documented in the man pages, further information in the csets. - Store percpu variables in vmlinux BTF. This can be disabled when debugging kernel features being developed to use it. - pahole now should be segfault free when handling gdb test suit DWARF files, including ADA, FORTRAN, rust and dwp compressed files, the later being just flatly refused, that got left for v1.19. - Bail out on partial units for now, avoiding segfaults and providing warning to user, hopefully will be addressed in v1.19. Closes: #977715. * Update Homepage link. Closes: #978708. * Drop debian/compat in favor of Build-Depends: debhelper-compat. * Fix typo in pahole manual page. * Fix escaping in pahole manual page. * Fix debian/copyright lintian errors. * Revert test to a superficial pahole --version until partial units become supported. [ Luca Boccassi ] * Use packaged libbpf instead of the statically linked. Closes: #979105. -- Domenico Andreoli Sun, 03 Jan 2021 13:41:31 +0100 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#958212: RFS: dwarves-dfsg/1.17-1 -- set of advanced DWARF utilities
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.17-1 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.17-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.17-1) unstable; urgency=low * New upstream release (changes since 1.16): BTF loader: - Support raw BTF as available in /sys/kernel/btf/vmlinux. pahole: - When the sole argument passed isn't a file, take it as a class name: - Do not require a class name to operate without a file name. - Make --find_pointers_to consider unions: - Make --contains and --find_pointers_to honour --unions - Add support for finding pointers to void: - Make --contains and --find_pointers_to to work with base types: - Make --contains look for more than just unions, structs: - Consider unions when looking for classes containing some class: - Introduce --unions to consider just unions: - Fix -m/--nr_methods - Number of functions operating on a type pointer man-pages: - Add section about --hex + -E to locate offsets deep into sub structs. - Add more information about BTF. - Add some examples. * Update to Standards-Version 4.5.0: - Drop get-orig-source rules target - Add Rules-Requires-Root: no * Update debhelper compat to 12. -- Domenico Andreoli Sun, 19 Apr 2020 20:25:33 +0200 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Looking for sponsor (was RFS: dwarves-dfsg 1.16-1)
Hi again, On Fri, Jan 17, 2020 at 09:57:17PM +0100, Domenico Andreoli wrote: > Package: sponsorship-requests > Severity: normal > > Dear all, > > I'm looking for a sponsor for this package: I'm still looking for the sponsor... :) Thanks, Domenico > > * Package name: dwarves-dfsg > Version : 1.16-1 > Upstream Author : Arnaldo Carvalho de Melo > * URL : http://acmel.wordpress.com > * License : GPLv2 > Section : utils > > It builds these binary packages: > > dwarves - set of advanced DWARF utilities > dwarves-dbgsym- debug symbols for dwarves > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/dwarves-dfsg > > > Alternatively, you can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.16-1.dsc > > More information can be obtained from > https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ > > Changes since the last upload: > > dwarves-dfsg (1.16-1) unstable; urgency=low > > * New upstream release (changes since 1.15): > - Preserve and encode exported functions as BTF_KIND_FUNC > - Add support for BTF_KIND_FUNC > - Account inline type __aligned__ member types for spacing > - Fix alignment of class members that are structs/enums/unions > - Fixup handling classes with no members, solving a NULL deref > - Avoid infinite loop trying to determine type with static data > member of its own type. > - type->type == 0 is void, fix --compile for that > - Print DW_TAG_subroutine_type as well > - Fix ptr_table__add_with_id() handling of pt->nr_entries, covering > how BTF variables IDs are encoded > - Allow passing the format path specifier, to use with BTF > - Fixup issues pointed out by various coverity reports > > -- Domenico Andreoli Wed, 15 Jan 2020 18:02:11 +0100 > > Kind regards, > Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#949182: RFS: dwarves-dfsg 1.16-1
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.16-1 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.16-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.16-1) unstable; urgency=low * New upstream release (changes since 1.15): - Preserve and encode exported functions as BTF_KIND_FUNC - Add support for BTF_KIND_FUNC - Account inline type __aligned__ member types for spacing - Fix alignment of class members that are structs/enums/unions - Fixup handling classes with no members, solving a NULL deref - Avoid infinite loop trying to determine type with static data member of its own type. - type->type == 0 is void, fix --compile for that - Print DW_TAG_subroutine_type as well - Fix ptr_table__add_with_id() handling of pt->nr_entries, covering how BTF variables IDs are encoded - Allow passing the format path specifier, to use with BTF - Fixup issues pointed out by various coverity reports -- Domenico Andreoli Wed, 15 Jan 2020 18:02:11 +0100 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05 signature.asc Description: PGP signature
Bug#941606: RFS: dwarves/1.15-2
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.15-2 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.15-2.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.15-2) unstable; urgency=low * Fix hardening-no-bindnow. * Fix debian-watch-uses-insecure-uri. * Fix debian-watch-does-not-check-gpg-signature. * Fix priority-extra-is-replaced-by-priority-optional. * Revert to dwarves-dbgsym for tests execution but skip the test if it's not installable (i.e. on transition to testing). -- Domenico Andreoli Mon, 23 Sep 2019 18:21:35 +0200 Kind regards, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Wed, Feb 27, 2019 at 02:10:06PM +0100, Adam Borowski wrote: > On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote: > > On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote: > > > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > > > > * Package name: dwarves-dfsg > > > > Version : 1.12-2 > > > > > * Update copyright to copyright-format/1.0. Closes: #919356. > > > > The new copyright file contains references to GPL-2.0-only and > > > GPL-2.0-or-later without defining them. > > > > According to https://spdx.org/licenses/ they are defined and supersede > > GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm > > reading that as long as copyright-format is not updated, new ones should > > not be used. > > SPDX has nothing to the copyright-format. The latter doesn't care about > short names at all, merely that 1. every file has a license, and 2. every > license is defined. > > Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow" > and "Cthulhu-fhtagn" have exactly the same meaning: they're merely > identifiers that need to be defined elsewhere in the file. Obviously, > for human readers we still want GPL to mean GPL -- but it's a syntax vs > content distinction. Got it, in my mind the two things were related. There is even a paragraph that says "For SPDX compatibility, versions with trailing dot-zeroes are considered to be equivalent to versions without (e.g., “2.0.0” is considered equal to “2.0” and “2”)." but I cannot ignore the one saying: "Use of a standard short name does not override the Debian Policy requirement to include the full license text in debian/copyright, nor any requirements in the license of the work regarding reproduction of legal notices. This information must still be included in the License field, either in a stand-alone License paragraph or in the relevant files paragraph." > > I spent quite some time in trying to understand what lintian tries > > to tell me here. I verified that reshuffling the file does not help > > either, these errors stay in a similar location, as if lintian had some > > bug somewhere. > > "references a license, for which no standalone license paragraph exists" I evidently read too little and assumed too much. > > I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly. > > I don't see it on mentors yet... I rewrote history and pushed a new 1.12-2 release to mentors. Thanks again for the feedback. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote: > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote: > > * Package name: dwarves-dfsg > > Version : 1.12-2 > > > Changes since the last upload: > > > > dwarves-dfsg (1.12-2) unstable; urgency=medium > > > > * Convert to dh. > > * Fix Homepage and Vcs-Git. > > * Fix depends on debhelper >= 10. > > * Remove trailing spaces from the Debian changelog. > > * Update copyright to copyright-format/1.0. Closes: #919356. > > Hi! Hi, > The new copyright file contains references to GPL-2.0-only and > GPL-2.0-or-later without defining them. According to https://spdx.org/licenses/ they are defined and supersede GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm reading that as long as copyright-format is not updated, new ones should not be used. Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere: W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ (paragraph at line 102) N: N:The files paragraph in the machine readable copyright file references a N:license, for which no standalone license paragraph exists. N: N:Refer to N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for N:details. N: N:Severity: normal, Certainty: possible N: N:Check: source-copyright, Type: source N: W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 (paragraph at line 94) I spent quite some time in trying to understand what lintian tries to tell me here. I verified that reshuffling the file does not help either, these errors stay in a similar location, as if lintian had some bug somewhere. I also expected they to be repeated as many times as in the files (yes, I'm using --no-tag-display-limit -i) but they are not and so at certain point I gave up. I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly. Thanks for reviewing. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)
Package: sponsorship-requests Severity: important Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.12-2 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.12-2.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.12-2) unstable; urgency=medium * Convert to dh. * Fix Homepage and Vcs-Git. * Fix depends on debhelper >= 10. * Remove trailing spaces from the Debian changelog. * Update copyright to copyright-format/1.0. Closes: #919356. -- Domenico Andreoli Wed, 26 Dec 2018 17:40:31 +0100 Kind regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Re: Building a shared library with no SONAME
On Wed, Feb 06, 2019 at 12:26:24PM -0500, Nicolas Mora wrote: > Le 2019-02-06 11:59, Andrey Rahmatullin a écrit : > > It's a bad idea to package shared libraries that don't keep stable ABI. > > > [...] > > > Please don't just add a random SONAME. Library versions with different > > ABIs must have different SONAMEs so if you add a custom SONAME you will > > need to change it each time the ABI changes, with an appropriate package > > transition. You may probably want to put the package version or the date > > into the SONAME like e.g. libv8 does. Your other option, apart from the > > obvious one (waiting for the issue to be fixed upstream), would be > > comparing ABIs and maintaining the ABI yourself but I wouldn't recommend > > it. > > You're right, on second thoughts, this library, even useful, doesn't have a > stable API yet, and will probably have more changes until a stable release. > > I'll close the ITP for now. I may reopen it when the library will be > stabalized. You could even leave the ITP open and mention the API instability in it so to prevent new "unaware" or "unwise" ITPs to succeed without further investigation. Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#917250: RFS: dwarves/1.12-1
On Tue, Dec 25, 2018 at 12:59:20PM +0100, Adam Borowski wrote: > On Mon, Dec 24, 2018 at 06:49:34PM +0100, Domenico Andreoli wrote: > > I'm looking for a sponsor for this package: > > Hi! I assume you have a problem with your gpg key. Hi Adam, Merry Christmas! Indeed my old 1024 bit key has been dropped some time ago and the new one has not enough signatures. And I've been very busy elsewhere in the meanwhile :) > > * Package name: dwarves-dfsg > > Version : 1.12-1 > > > dwarves-dfsg (1.12-1) unstable; urgency=medium > > > > [ Domenico Andreoli ] > > * New upstram release. Closes: #908563, #779809, #693096, > > * Migrate to salsa.d.o and enable CI. Closes: #908564. > > * Migrate to DEP-14. > > * Drop patch DW_TAG_mutable_type (merged upstream). > > * Refresh patch no_shared_no_ebl. > > * Improve package description. Closes: #914527. > > * Add test executing pahole on itself. > > * Set debhelper compatibility level to 10. > > * Start using dh_strip_nondeterminism. > > > > [ Helmut Grohne ] > > * Let dh_auto_configure pass cross flags to cmake. Closes: #903506. > > I have no complaints other than what lintian says (yet?), but with so many > warnings that are trivially fixable it'd be better to give it at least some > heed. Improper debhelper versioning hurts backports, using a ssh URL for > VCS- breaks QA pages, etc. my intention is to address as many as possible but I am not the fastest bullet on the market and it may take some more time. > On the other hand, if you insist because of wanting the new release in while > you're not capable of caring for less important matters, please say so -- > these are only warnings rather than show-stoppers. OTOH we are not far from the freeze and would not dislike to have a first push, just to be sure Buster get a [dr]ecent version or that we catch any real blocker earlier. Thanks for your support. Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Bug#917250: RFS: dwarves/1.12-1
Package: sponsorship-requests Severity: normal Dear all, I'm looking for a sponsor for this package: * Package name: dwarves-dfsg Version : 1.12-1 Upstream Author : Arnaldo Carvalho de Melo * URL : http://acmel.wordpress.com * License : GPLv2 Section : utils It builds these binary packages: dwarves - set of advanced DWARF utilities dwarves-dbgsym- debug symbols for dwarves To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dwarves-dfsg Alternatively, you can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dwarves-dfsg/dwarves-dfsg_1.12-1.dsc More information can be obtained from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ Changes since the last upload: dwarves-dfsg (1.12-1) unstable; urgency=medium [ Domenico Andreoli ] * New upstram release. Closes: #908563, #779809, #693096, * Migrate to salsa.d.o and enable CI. Closes: #908564. * Migrate to DEP-14. * Drop patch DW_TAG_mutable_type (merged upstream). * Refresh patch no_shared_no_ebl. * Improve package description. Closes: #914527. * Add test executing pahole on itself. * Set debhelper compatibility level to 10. * Start using dh_strip_nondeterminism. [ Helmut Grohne ] * Let dh_auto_configure pass cross flags to cmake. Closes: #903506. -- Domenico Andreoli Mon, 19 Nov 2018 18:11:43 +0100 Kind regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Re: Troubles with mentors.debian.net
On November 28, 2018 6:50:07 PM UTC, Mattia Rizzolo wrote: >Hi! Hi! >On Wed, Nov 28, 2018 at 06:17:20PM +0100, Domenico Andreoli wrote: >> The first roadblock is that I'm already registered on >mentors.debian.org >> as DD, from the times I was active, and now I cannot switch the role >> for uploading any package. > >I don't understand this part, sorry. >Sure, there is an account with your email, which I suppose is your >account, but I don't understand what's the problem. I was expecting to see some upload button. After your email and reading again the instructions I now know the obvious answer: dput. >(Also, for mentors.d.n support, the address is support@mentors.d.n, >though d-mentors works as well if there aren't private data involved) Good to know, I'll try to remember for the next time Thanks, Domenico
Troubles with mentors.debian.net
Hi all, as suggested on debian-devel [0], I'm following the procedure so to find a sponsor for the new upload of dwarves I'm preparing [1]. The first roadblock is that I'm already registered on mentors.debian.org as DD, from the times I was active, and now I cannot switch the role for uploading any package. Of course I can register a new account but I was wondering if this is indeed the best move. Any suggestions? Kind regards, Domenico [0] https://lists.debian.org/debian-devel/2018/11/msg00555.html [1] https://lists.debian.org/debian-devel/2018/11/msg00524.html -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Re: Some problems with debian/rules file...
On Wed, Sep 26, 2001 at 10:36:24PM +1000, Jeremy Higgs wrote: Hi everyone, hi I'm trying to make a package for RCF (a firewall) that will be used, via a Makefil, to compile the current CVS version of RCF... It seems to be working ok, but a part of the 'install' target in the debian/rules file seems to be skipped when I run 'dpkg-buildpackage'...: let's see all debian/rules, uh? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some problems with debian/rules file...
On Wed, Sep 26, 2001 at 10:36:24PM +1000, Jeremy Higgs wrote: Hi everyone, hi I'm trying to make a package for RCF (a firewall) that will be used, via a Makefil, to compile the current CVS version of RCF... It seems to be working ok, but a part of the 'install' target in the debian/rules file seems to be skipped when I run 'dpkg-buildpackage'...: let's see all debian/rules, uh? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: What to do with sources that lack a copyright
and what about sources without any copyright statement? On Fri, Sep 21, 2001 at 02:59:28PM +0200, Andreas Rottmann wrote: I'm right now trying to debianize sqlite (will post ITP later) and in the process change the build system to use automake (to make things more understandable ;-)). The sqlite source is uncopyrighted (quote from the homepage http://www.hwaci.com/sw/sqlite/: Sources are uncopyrighted. Use for any purpose.). Can I simply put this explanation into the /usr/share/doc/sqlite/copyright file, or should I choose a licence (e.g. GPL/LGPL) for the packages? I could justify that by the not-so-small changes in the build system. Thanks for any hints, Andy -- Andreas Rottmann | Dru@ICQ| 118634484@ICQ | [EMAIL PROTECTED] Georg-Rendlweg 28| A-5111 Bürmoos | Austria | Europe http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do with sources that lack a copyright
and what about sources without any copyright statement? On Fri, Sep 21, 2001 at 02:59:28PM +0200, Andreas Rottmann wrote: I'm right now trying to debianize sqlite (will post ITP later) and in the process change the build system to use automake (to make things more understandable ;-)). The sqlite source is uncopyrighted (quote from the homepage http://www.hwaci.com/sw/sqlite/: Sources are uncopyrighted. Use for any purpose.). Can I simply put this explanation into the /usr/share/doc/sqlite/copyright file, or should I choose a licence (e.g. GPL/LGPL) for the packages? I could justify that by the not-so-small changes in the build system. Thanks for any hints, Andy -- Andreas Rottmann | [EMAIL PROTECTED]| [EMAIL PROTECTED] | [EMAIL PROTECTED] Georg-Rendlweg 28| A-5111 Bürmoos | Austria | Europe http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: dpkg-shlibdeps strange messages and lintian error (rpath)
On Sun, Sep 16, 2001 at 10:11:52PM +0200, Othmar Pasteka wrote: hi, hi :) second, i get the lintian warning: W: modlogan: binary-or-shlib-defines-rpath ./usr/bin/modlogan /usr/lib/modlogan i can't really tell what's wrong with this ... please enlighten me here as well. be sure to build your binaries in the build target of your debian/rules -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-shlibdeps strange messages and lintian error (rpath)
On Sun, Sep 16, 2001 at 10:11:52PM +0200, Othmar Pasteka wrote: hi, hi :) second, i get the lintian warning: W: modlogan: binary-or-shlib-defines-rpath ./usr/bin/modlogan /usr/lib/modlogan i can't really tell what's wrong with this ... please enlighten me here as well. be sure to build your binaries in the build target of your debian/rules -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Fri, Sep 07, 2001 at 12:09:39PM +0200, Christian Marillat wrote: DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: versioned shlibs file -- when and why
On Sun, Sep 02, 2001 at 04:04:11PM -0400, Steve M. Robbins wrote: On Sun, Sep 02, 2001 at 01:22:32PM -0500, Steve Langasek wrote: Version 2.1.1 of libfoo provides functions foo_open, foo_close. Version 2.1.2 of libfoo provides functions foo_open, foo_close, and foo_read. This doesn't break the ABI; foo_open and foo_close have not changed, so there's no need to increment the library so number (and thereby change the package name). However, a binary compiled against libfoo 2.1.2 that uses foo_read will /not/ work with libfoo 2.1.1, so you need a version in shlibs. This suggests that one ought to increase the version in the shlibs file each time the ABI is changed, but not change it otherwise. So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: versioned shlibs file -- when and why
On Fri, Sep 07, 2001 at 12:09:39PM +0200, Christian Marillat wrote: DA == Domenico Andreoli [EMAIL PROTECTED] writes: [...] So is dh_makeshlibs -V (i.e. bump the version uncondtionally) simply the lazy-man's way of doing this? best solution INHO is to write .shlibs file by hand and update minimum version required every time you understand ABI is changing. upstream developer can help a lot in this. This is a file to edit and some maintainer forget that. you don't have to edit it all the time, only when your ABI changes :) A line like this in debian/rules is better IMHO. dh_makeshlibs -plibpanel-applet0 -V 'libpanel-applet0 (= 1.4.0.2-3)' i wasn't considering this option. what if you have to put more than one library in a .shlibs file? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 01:22:01PM -0500, Steve Langasek wrote: On Mon, 3 Sep 2001, Drew Parsons wrote: [...] Check the contents of the postinst script in the binary package. The #DEBHELPER# line gets replaced with debhelper hints based on the various dh_* commands you've called, and if you call dh_makeshlibs, this will include a call to ldconfig in the postinst and the postrm. this happens only if you set DH_COMPAT=3 somewhere in your debian/rules and if you are using debhelper, of course Which means you have two calls to ldconfig in the resulting postinst script, and lintian is expecting only one. :) Cheers, Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 01:22:01PM -0500, Steve Langasek wrote: On Mon, 3 Sep 2001, Drew Parsons wrote: [...] Check the contents of the postinst script in the binary package. The #DEBHELPER# line gets replaced with debhelper hints based on the various dh_* commands you've called, and if you call dh_makeshlibs, this will include a call to ldconfig in the postinst and the postrm. this happens only if you set DH_COMPAT=3 somewhere in your debian/rules and if you are using debhelper, of course Which means you have two calls to ldconfig in the resulting postinst script, and lintian is expecting only one. :) Cheers, Steve Langasek postmodern programmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 08:44:40PM +1000, Drew Parsons wrote: My package meschach has a shared library. Previously, I called ldconfig in the postinst to get the library registered (it was made mandatory in Policy 2.4.1.0). But I've noticed just now as I prepare a new upload that lintain complains, saying, W: meschach: postinst-has-useless-call-to-ldconfig So I'm a bit confused about what the problem is, especially since the directive in Policy 2.4.1.0 doesn't appear to have been annulled. it is useless to call ldconfig if you don't install any shared library in paths which ldconfig look for libraries in, right? so lintian does this check to prevent useless calls to ldconfig, maybe this help you understanding you are not installing libraries where maybe you are expecting them to be installed (which maybe are right the paths scanned by ldconfig). anyway there was a bug (#109721) and lintian reported this warning even if you were effectively installing libraries in ldconfig path. this bugs has been solved and upgrading to newer versions of lintian should make you less confused :(( remember also to call ldconfig in postrm only with remove argument (see policy chapter 9) (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems fine without it) yes you should always call it if you are building any sort of binaries which may depends on other binaries (ie. executables and shared libraries). please remember that any library that uses libc must be compiled against but not have a dependency on it since libc is essential package (exception is required if you need a particular version of it). My postinst is: #!/bin/sh # meschach.postinst, runs ldconfig set -e case $1 in configure) ldconfig ;; abort-upgrade|abort-remove|abort-deconfigure) ;; esac #DEBHELPER# ## this is correct Thanks for any clues or explanations, you are welcome :) Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am trying to learn how to build packages.
On Mon, Sep 03, 2001 at 02:17:03PM +0100, William wrote: Not sure what to put in this field. I was directed here by someone. which field? better to start from the beginning, please visit - http://www.debian.org/devel/ - http://www.debian.org/doc/debian-policy/ - http://www.debian.org/doc/maint-guide/ do not expect it to be easy - Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldconfig in postinst
On Mon, Sep 03, 2001 at 08:44:40PM +1000, Drew Parsons wrote: My package meschach has a shared library. Previously, I called ldconfig in the postinst to get the library registered (it was made mandatory in Policy 2.4.1.0). But I've noticed just now as I prepare a new upload that lintain complains, saying, W: meschach: postinst-has-useless-call-to-ldconfig So I'm a bit confused about what the problem is, especially since the directive in Policy 2.4.1.0 doesn't appear to have been annulled. it is useless to call ldconfig if you don't install any shared library in paths which ldconfig look for libraries in, right? so lintian does this check to prevent useless calls to ldconfig, maybe this help you understanding you are not installing libraries where maybe you are expecting them to be installed (which maybe are right the paths scanned by ldconfig). anyway there was a bug (#109721) and lintian reported this warning even if you were effectively installing libraries in ldconfig path. this bugs has been solved and upgrading to newer versions of lintian should make you less confused :(( remember also to call ldconfig in postrm only with remove argument (see policy chapter 9) (and do I need to put dpkg-shlibdeps in debian/rules somewhere? It seems fine without it) yes you should always call it if you are building any sort of binaries which may depends on other binaries (ie. executables and shared libraries). please remember that any library that uses libc must be compiled against but not have a dependency on it since libc is essential package (exception is required if you need a particular version of it). My postinst is: #!/bin/sh # meschach.postinst, runs ldconfig set -e case $1 in configure) ldconfig ;; abort-upgrade|abort-remove|abort-deconfigure) ;; esac #DEBHELPER# ## this is correct Thanks for any clues or explanations, you are welcome :) Drew -- PGP public key available at http://dparsons.webjump.com/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: I am trying to learn how to build packages.
On Mon, Sep 03, 2001 at 02:17:03PM +0100, William wrote: Not sure what to put in this field. I was directed here by someone. which field? better to start from the beginning, please visit - http://www.debian.org/devel/ - http://www.debian.org/doc/debian-policy/ - http://www.debian.org/doc/maint-guide/ do not expect it to be easy - Will -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: 1st try at packaging perl program
On Fri, Jun 29, 2001 at 08:12:58AM +0100, Etienne Grossmann wrote:
Hello,
hi
Depends: ${shlibs:Depends},${perl:Depends}
did you try to use debhelper and dh_perl?
cheers
-[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 1st try at packaging perl program
On Fri, Jun 29, 2001 at 08:12:58AM +0100, Etienne Grossmann wrote:
Hello,
hi
Depends: ${shlibs:Depends},${perl:Depends}
did you try to use debhelper and dh_perl?
cheers
-[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: aspell compilation failed on arm: please help
On Wed, Jun 27, 2001 at 03:05:50PM +0200, Robert Bihlmeyer wrote: Domenico Andreoli [EMAIL PROTECTED] writes: what i don't understand follows: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. i suppose the command following this statement fails because of the problem claimed by it, but i still don't figure out what does it means. Normally, when you link in a shared library into a program, the program will not contain code from that library, just stubs that are resolved at runtime *and* will depend on it. This dependencies are what shows up on ldd BINARY. If you link a shared library with a shared library, the same should happen, but some library formats do not support this feature. The message means that libtool suspects this system to be one of these. (see also (libtool)Inter-library Dependencies in the info pages). libtool is actually wrong, because all common Linux ports use ELF, which supports inter-library dependencies (accordingly, you can see those with ldd LIBRARY). hmm... yes I don't think that the following error (libtool issues: gcc [...] -o .libs/) has the same cause, apart from the fact that it's libtool's fault again: -o must name a target file, not a directory. ok, i knew it was libtool to be wrong :)) aspell contains libtool 1.3c, which is old. Your best bet at the moment is running libtoolize --force in its top level directory while having a modern libtool package installed. This may well fix those bugs (or not). yes, i'll try thanks -- Robbe -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aspell compilation failed on arm: please help
i'm not the maintainer of aspell, anyway i'm trying to make it ok, with permession of its maintainer. it doesn't compile on arm, the log is here http://buildd.armlinux.org/~buildd/build.php?pkg%3Daspell%26ver%3D0.32.6-3.2%26arch%3Darm%26stamp%3D993266812 what i don't understand follows: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. i suppose the command following this statement fails because of the problem claimed by it, but i still don't figure out what does it means. thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: one package, many libraries. dependency break!
On Fri, Jun 15, 2001 at 09:39:58PM +0300, Richard Braakman wrote: On Fri, Jun 15, 2001 at 07:28:47PM +0200, Domenico Andreoli wrote: the problem is dpkg-shlibdeps that figures out the package(s) from which this should depend on. in fact it sees that libpspell-impl depends on libpspell and adds libpspell2 (which is the package that provides it, that is this) to the dependecy list. so i get a package that depends on itself. Actually dpkg-shlibdeps will use the shlibs file of the installed version of libpspell2, not the one you're building. This is even worse :) you are correct In the past I have solved this problem by invoking dpkg-shlibdeps with a LD_LIBRARY_PATH setting that makes it find the libaries in the build tree. This way you get a warning that it couldn't find what package provides them, but you don't get a bogus dependency. I haven't found a cleaner solution. is LD_LIBRARY_PATH solution alternative to shlibs files? and if a libspell is already installing on the building system? wouldn't i need to put a !libpspell2 in Build-Depends? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
one package, many libraries. dependency break!
i'm working on a package (libpspell2) which installthree libraries (libpspell.so.2.0.2, libpspell-impl.so.3.0.1, libpspell-modules.so.1.0.1), as expected it exports a shlibs which lists all of the three libs. they depend on each other :( the problem is dpkg-shlibdeps that figures out the package(s) from which this should depend on. in fact it sees that libpspell-impl depends on libpspell and adds libpspell2 (which is the package that provides it, that is this) to the dependecy list. so i get a package that depends on itself. any considerations? should i split this package in three?!? thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Integration of debian/ scripts in packages
On Tue, Jun 12, 2001 at 06:29:22PM +0100, Colin Watson wrote: [snip] I'm very glad to hear that work's being done on dpkg-source that should (if I understand it correctly) obsolete this hack. my i ask you what is the work on dpkg-source you are talking about? -- Colin Watson [[EMAIL PROTECTED]] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Integration of debian/ scripts in packages
On Tue, Jun 12, 2001 at 06:29:22PM +0100, Colin Watson wrote: [snip] I'm very glad to hear that work's being done on dpkg-source that should (if I understand it correctly) obsolete this hack. my i ask you what is the work on dpkg-source you are talking about? -- Colin Watson [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: 2 packages sharing the same config file.
On Fri, May 18, 2001 at 04:22:41AM +0200, [EMAIL PROTECTED] wrote: I just adopted xabacus. It conflicts with xmabacus because both try to install the same config file /etc/X11/app-defaults/Abacus. maybe using an abacus-common package which owns that conffile... my question now is, is a file worth of a package on its own?!? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
i need a sponsor for curl and hping2
hi * i need a sponsor to upload new releases of curl, curl-ssl and hping2, i put them in my repository here: deb http://web.tiscalinet.it/cavok/debian unstable main deb http://web.tiscalinet.it/cavok/debian unstable/non-US main deb-src http://web.tiscalinet.it/cavok/debian unstable main deb-src http://web.tiscalinet.it/cavok/debian unstable/non-US main with this upload of curl-ssl i should be able to close an ugly and stupid bug against curl-ssl, another critical bug aginst curl-ssl and an adjustments in hping2 in order to cope with dpkg-statoverride. thanks for your support -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
i need a sponsor for curl and hping2
hi * i need a sponsor to upload new releases of curl, curl-ssl and hping2, i put them in my repository here: deb http://web.tiscalinet.it/cavok/debian unstable main deb http://web.tiscalinet.it/cavok/debian unstable/non-US main deb-src http://web.tiscalinet.it/cavok/debian unstable main deb-src http://web.tiscalinet.it/cavok/debian unstable/non-US main with this upload of curl-ssl i should be able to close an ugly and stupid bug against curl-ssl, another critical bug aginst curl-ssl and an adjustments in hping2 in order to cope with dpkg-statoverride. thanks for your support -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpJYWby6aijX.pgp Description: PGP signature
Re: dependency mess: i'd like boolean operators
On Thu, Feb 08, 2001 at 09:07:11AM -0600, Richard Braakman wrote: On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote: the question is which dependencies should curl-ssl have? i'm thinking something like: Conflicts: curl(7.4.2-2) Depends: curl(=7.4.2-2), libcurl0-ssl(=7.4.2-2) | libcurl1-ssl(=7.5-1) If you Depend on curl = 7.4.2-2, then you don't need to also Conflict with older curl. the correct relation should be this: ( curl(=7.4.2-2) AND libcurl0-ssl(=7.4.2-2) ) OR ( curl(=7.5-1) AND libcurl1-ssl(=7.5-1) ) can be this relation achieved someway? Using Boolean logic this transforms to: Depends: curl (= 7.4.2-2) | curl (= 7.5-1), libcurl0-ssl (= 7.4.2-2) | curl (= 7.5-1), curl (= 7.4.2-2) | libcurl1-ssl (= 7.5-1), libcurl0-ssl (= 7.4.2-2) | libcurl1-ssl (= 7.5-1) this is really interesting, so let me understand more: 1) the first clause can be simplified as you said below, ok. 23) the second... should be "|" read as XOR (exclusive or)? there is no meaning in the order of the operands of "|", right? if what i said is correct then second and third cluses are ok. 4) the fourth clause has sense only if "|" has a XOR meaning. please correct me if i'm not right The first clause can be simplified to "curl (= 7.4.2-2)" if there were no versions in between. in fact there are no versions in between Doesn't each version of curl Depend on the library it needs? In that case it simplifies to: Depends: curl (= 7.4.2-2) this doesn't work, since curl(=7.4.2-2) depends on libcurl0 | libcurl0-ssl while curl(=7.5-1) depends on libcurl1 | libcurl1-ssl and i need to force the install of the ssl versions of the libcurl libraries in order to make curl understanding something about SSL. another point. potato has a 6.0-xxx series of curl packages, at that time libcurl was not even a separate package so the upgrade from potato shouldn't have all this mess. all this work could be a waste of time, since some upgrade problems in woody are ok since it is "testing". Then I don't think it's worth the complication. i realized that at the end of the message :) anyway thanks Richard Braakman Domenico Andreoli -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: dependency mess: i'd like boolean operators
On Thu, Feb 08, 2001 at 09:07:11AM -0600, Richard Braakman wrote: On Thu, Feb 08, 2001 at 03:39:33PM +0100, Domenico Andreoli wrote: the question is which dependencies should curl-ssl have? i'm thinking something like: Conflicts: curl(7.4.2-2) Depends: curl(=7.4.2-2), libcurl0-ssl(=7.4.2-2) | libcurl1-ssl(=7.5-1) If you Depend on curl = 7.4.2-2, then you don't need to also Conflict with older curl. the correct relation should be this: ( curl(=7.4.2-2) AND libcurl0-ssl(=7.4.2-2) ) OR ( curl(=7.5-1) AND libcurl1-ssl(=7.5-1) ) can be this relation achieved someway? Using Boolean logic this transforms to: Depends: curl (= 7.4.2-2) | curl (= 7.5-1), libcurl0-ssl (= 7.4.2-2) | curl (= 7.5-1), curl (= 7.4.2-2) | libcurl1-ssl (= 7.5-1), libcurl0-ssl (= 7.4.2-2) | libcurl1-ssl (= 7.5-1) this is really interesting, so let me understand more: 1) the first clause can be simplified as you said below, ok. 23) the second... should be | read as XOR (exclusive or)? there is no meaning in the order of the operands of |, right? if what i said is correct then second and third cluses are ok. 4) the fourth clause has sense only if | has a XOR meaning. please correct me if i'm not right The first clause can be simplified to curl (= 7.4.2-2) if there were no versions in between. in fact there are no versions in between Doesn't each version of curl Depend on the library it needs? In that case it simplifies to: Depends: curl (= 7.4.2-2) this doesn't work, since curl(=7.4.2-2) depends on libcurl0 | libcurl0-ssl while curl(=7.5-1) depends on libcurl1 | libcurl1-ssl and i need to force the install of the ssl versions of the libcurl libraries in order to make curl understanding something about SSL. another point. potato has a 6.0-xxx series of curl packages, at that time libcurl was not even a separate package so the upgrade from potato shouldn't have all this mess. all this work could be a waste of time, since some upgrade problems in woody are ok since it is testing. Then I don't think it's worth the complication. i realized that at the end of the message :) anyway thanks Richard Braakman Domenico Andreoli -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpugd0AmJCnn.pgp Description: PGP signature
help in interpreting the packaging manual
i need to put a "Conflicts: curl-ssl(7.6-2)" in the control file of my curl package since the curl-ssl packages newer then 7.6-2 know how to handle the co-existence. now reading the packaging manual i found this writing: "A Conflicts entry should almost never have an `earlier than' version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. This aspect of installation ordering is not handled by dselect, so that the use Conflicts in this way is likely to cause problems for `bulk run' upgrades and installations." now i'm not really undestanding the point, is it telling me i'm going to have problems during upgrade? what does it mean "bulk run"? please help me interpreting it correctly. thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
help in interpreting the packaging manual
i need to put a Conflicts: curl-ssl(7.6-2) in the control file of my curl package since the curl-ssl packages newer then 7.6-2 know how to handle the co-existence. now reading the packaging manual i found this writing: A Conflicts entry should almost never have an `earlier than' version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. This aspect of installation ordering is not handled by dselect, so that the use Conflicts in this way is likely to cause problems for `bulk run' upgrades and installations. now i'm not really undestanding the point, is it telling me i'm going to have problems during upgrade? what does it mean bulk run? please help me interpreting it correctly. thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpIz6mBLToQ8.pgp Description: PGP signature
dependency mess: i'd like boolean operators
i know that this topic has been already discussed in this list but
i'm not finding the messages i need, so please help me.
my curl package has been uploaded with the following version numbers:
...[some older]...
7.4.2-1
7.4.2-2
7.5-1
...[some newer]...
until 7.4.2-1 included, curl and curl-ssl were two completely separated
source and binary packages. each of them had its own set of libraries
and developing files etc.
on 7.4.2-2 i realized that the curl binararies were completely identical
and that the SSL functionality was achieved thanks to the different
version of libcurl they were installed with (libcurl is the library
which each of them is linked to). so i made a curl binary package (the
one in main) depending on either libcurl or libcurl-ssl and removed
curl-ssl from the archives.
starting from 7.5-1 libcurl (which in reality was in libcurl0 package)
started having a serious versioning upstream and i packaged it in
libcurl1 (its major version number is 1, so it is ok).
now i need a curl-ssl dummy package depending on curl and libcurl{0|1}
in order to smoothend the upgrade from potato.
the question is which dependencies should curl-ssl have?
i'm thinking something like:
Conflicts: curl(7.4.2-2)
Depends: curl(=7.4.2-2), libcurl0-ssl(=7.4.2-2) | libcurl1-ssl(=7.5-1)
in fact curl-ssl should conflict only with curl(7.4.2-2) (ence my
previous post) and depend on curl(=7.4.2-2), that's ok. what about
the libraries? if the release we are upgrading from is (7.4.2-2),
we should depend on libcurl0-ssl, if it is (=7.5-1) we should depend
on libcurl1-ssl(=7.5-1).
the correct relation should be this:
( curl(=7.4.2-2) AND libcurl0-ssl(=7.4.2-2) ) OR ( curl(=7.5-1) AND
libcurl1-ssl(=7.5-1) )
can be this relation achieved someway?
another point. potato has a 6.0-xxx series of curl packages, at that time
libcurl was not even a separate package so the upgrade from potato shouldn't
have all this mess. all this work could be a waste of time, since some
upgrade problems in woody are ok since it is testing.
let me know what do you think about this story.
thanks in advance
ps: sorry for the long message and the long lines
-[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
pgpTBiHHwN26P.pgp
Description: PGP signature
please help me with #78232
hi all i have a problem with bug #78232 which i don't figure out how to solve. it is the assle of the -rpath parameter. lintian is reporting this warning against my curl binary package and i'm not understanding how to make it shut up. lintian doesn't provide any information regarding this warning. times ago, when -rpath was an issue, lintian had an explanation and a link for a workaround, now it hasn't. in the lintian changelog is written that libtool doesn't force the use of -rpath switch any more, but i still get it. i was told to run libtool -f in my source tree but it didn't solved anything. let me know if i can close this bug as is or i need to do something more. if this is not a matter any more shouldn't lintian be upgraded in order to not raising this warning any more? thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgp4xyDgWsWTX.pgp Description: PGP signature
Re: lintian: binary-has-unneeded-section
On Fri, Feb 02, 2001 at 11:17:23PM +1100, Drew Parsons wrote: Getting back to the meschach libraries, which I was asking about a little while ago, when I run lintian on the built packages, I get the following error report: W: meschach-dev: postinst-has-useless-call-to-ldconfig W: meschach: binary-has-unneeded-section ./usr/lib/libmeschach.so.1.2 .note W: meschach: binary-has-unneeded-section ./usr/lib/libmeschach.so.1.2 .comment I got no idea whatsoever what the second two messages mean. I'm compiling the library with flags -fPIC to get a shared library. What's all this about uneeded sections, notes and comments? sorry, i cannot help you, anyway have you tried lintian -i? it is a little more verbose about its outputs. cheers -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: lintian: binary-has-unneeded-section
On Fri, Feb 02, 2001 at 11:17:23PM +1100, Drew Parsons wrote: Getting back to the meschach libraries, which I was asking about a little while ago, when I run lintian on the built packages, I get the following error report: W: meschach-dev: postinst-has-useless-call-to-ldconfig W: meschach: binary-has-unneeded-section ./usr/lib/libmeschach.so.1.2 .note W: meschach: binary-has-unneeded-section ./usr/lib/libmeschach.so.1.2 .comment I got no idea whatsoever what the second two messages mean. I'm compiling the library with flags -fPIC to get a shared library. What's all this about uneeded sections, notes and comments? sorry, i cannot help you, anyway have you tried lintian -i? it is a little more verbose about its outputs. cheers -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpl1CvnmZrG4.pgp Description: PGP signature
Re: the incoming queue for non-US?
On Thu, Jan 25, 2001 at 09:06:18PM +1100, Hamish Moffatt wrote: On Wed, Jan 24, 2001 at 05:36:38PM +0100, Domenico Andreoli wrote: i'm looking for the incoming queue for non-US. as i see in the debian developer reference, it seems it is reserved only for debian developer. All of the upload queues are reserved for developers. The indirect queues will allow anonymous FTP uploads, but the uploads will not actually be processed and installed into Debian without a PGP or GPG signature from a Debian developer. yes i know, that's right. what i'd like to do is to check what has been uploaded by my sponsor and to look at the reports in case of rejection. for main i look at http://incoming.debian.org, for non-US? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: binary-or-shlib-defines-rpath: please help me to undestand (bug #78232)
On Wed, Jan 24, 2001 at 06:30:11PM -0600, Steve Langasek wrote: On Wed, 24 Jan 2001, Domenico Andreoli wrote: On Wed, Jan 24, 2001 at 11:39:12AM -0600, Steve Langasek wrote: On Wed, 24 Jan 2001, Domenico Andreoli wrote: uh? how is dpkg-shlibdeps related to libtool?!? Ah... sorry, I saw two posts from you in a row, and assumed the two were related. I guess I replied to the wrong one. :) anyway i was wondering how i can make my curl depends up on a library that is not in any directoory of my hd? libcurl1 is generate together with curl, but libcurl1-ssl is not. i want curl depends upon one of those libraries. Domenico, Steve, This may be too complex for me to help with. I'm a novice developer, and I don't know as much as I'd like to about shlibdeps. Does the shlibs.local file you posted work the way you want it to? If so, oh my shlibs.local works the way i want. it's ok. adding the LD_LIBRARY_PATH to dpkg-shlibdeps will fix the warning message... I don't know what else needs fixing? what i want to understand end to fix is this error message. ^^ thanks anyway -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: the incoming queue for non-US?
On Thu, Jan 25, 2001 at 09:06:18PM +1100, Hamish Moffatt wrote: On Wed, Jan 24, 2001 at 05:36:38PM +0100, Domenico Andreoli wrote: i'm looking for the incoming queue for non-US. as i see in the debian developer reference, it seems it is reserved only for debian developer. All of the upload queues are reserved for developers. The indirect queues will allow anonymous FTP uploads, but the uploads will not actually be processed and installed into Debian without a PGP or GPG signature from a Debian developer. yes i know, that's right. what i'd like to do is to check what has been uploaded by my sponsor and to look at the reports in case of rejection. for main i look at http://incoming.debian.org, for non-US? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpOSjUYi5JiJ.pgp Description: PGP signature
Re: binary-or-shlib-defines-rpath: please help me to undestand (bug #78232)
On Wed, Jan 24, 2001 at 06:30:11PM -0600, Steve Langasek wrote: On Wed, 24 Jan 2001, Domenico Andreoli wrote: On Wed, Jan 24, 2001 at 11:39:12AM -0600, Steve Langasek wrote: On Wed, 24 Jan 2001, Domenico Andreoli wrote: uh? how is dpkg-shlibdeps related to libtool?!? Ah... sorry, I saw two posts from you in a row, and assumed the two were related. I guess I replied to the wrong one. :) anyway i was wondering how i can make my curl depends up on a library that is not in any directoory of my hd? libcurl1 is generate together with curl, but libcurl1-ssl is not. i want curl depends upon one of those libraries. Domenico, Steve, This may be too complex for me to help with. I'm a novice developer, and I don't know as much as I'd like to about shlibdeps. Does the shlibs.local file you posted work the way you want it to? If so, oh my shlibs.local works the way i want. it's ok. adding the LD_LIBRARY_PATH to dpkg-shlibdeps will fix the warning message... I don't know what else needs fixing? what i want to understand end to fix is this error message. ^^ thanks anyway -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpT7BxmELJd6.pgp Description: PGP signature
binary-or-shlib-defines-rpath: please help me to undestand (bug #78232)
my package (curl) get this warning from lintian. i tryed to gain more information from lintian by using -i switch but i don't get them. my package uses libtool and the ill-famed -rpath parameter. i run libtoolize -fc in order to update the libtool files in the build tree but i still have the problem. anybody has any idea about solving this problem, it is bug #78232. thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
the incoming queue for non-US?
hi all i'm looking for the incoming queue for non-US. as i see in the debian developer reference, it seems it is reserved only for debian developer. thanks for any help -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
binary-or-shlib-defines-rpath: please help me to undestand (bug #78232)
my package (curl) get this warning from lintian. i tryed to gain more information from lintian by using -i switch but i don't get them. my package uses libtool and the ill-famed -rpath parameter. i run libtoolize -fc in order to update the libtool files in the build tree but i still have the problem. anybody has any idea about solving this problem, it is bug #78232. thanks -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpBaGDeSQmyY.pgp Description: PGP signature
the incoming queue for non-US?
hi all i'm looking for the incoming queue for non-US. as i see in the debian developer reference, it seems it is reserved only for debian developer. thanks for any help -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpnaQpTXag1q.pgp Description: PGP signature
Re: How to deal with lintian E: missing shlibs information
On Fri, Dec 22, 2000 at 02:34:29AM +0900, Junichi Uekawa wrote: The thing I want to know is, that it is a "libpyecasound.so", and it doesn't have the numbers after it. it really seems to be a plug-in. please look for headers files and other development files. if they miss it is not a shared library. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: Multiple Binary-Package - exclude one binary for an architecture
On Fri, Dec 22, 2000 at 03:25:54PM +0100, Cord Beermann wrote: Hi. ciao I've build a package which includes two binaries (jove, an editor with a X-Frontend). Now i've found out that i can't build the X-Frontend on the Hurd yet (missing xview-dev). How can i produce a source-package, that simply builds only the editor on the hurd, and builds both packages on the other architectures? in debian/control you have to put in "Architecture" field all the archs but hurd for the package that will not compile unde hurd. It would be enough if someone could point me to a package which does this. i'll point to the relevant page of the packaging manual, but feel free to read it all :)) http://www.debian.org/doc/packaging-manuals/packaging.html/ch-controlfields.html Thanks, Cord you are welcome! -- Cord Beermann [EMAIL PROTECTED] (Privat) ~ ASCII Ribbon Campaign X Say NO to HTML in email and news / \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 PGP signature
Re: How to deal with lintian E: missing shlibs information
On Fri, Dec 22, 2000 at 02:34:29AM +0900, Junichi Uekawa wrote: The thing I want to know is, that it is a libpyecasound.so, and it doesn't have the numbers after it. it really seems to be a plug-in. please look for headers files and other development files. if they miss it is not a shared library. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpqibQmqZgMm.pgp Description: PGP signature
Re: Multiple Binary-Package - exclude one binary for an architecture
On Fri, Dec 22, 2000 at 03:25:54PM +0100, Cord Beermann wrote: Hi. ciao I've build a package which includes two binaries (jove, an editor with a X-Frontend). Now i've found out that i can't build the X-Frontend on the Hurd yet (missing xview-dev). How can i produce a source-package, that simply builds only the editor on the hurd, and builds both packages on the other architectures? in debian/control you have to put in Architecture field all the archs but hurd for the package that will not compile unde hurd. It would be enough if someone could point me to a package which does this. i'll point to the relevant page of the packaging manual, but feel free to read it all :)) http://www.debian.org/doc/packaging-manuals/packaging.html/ch-controlfields.html Thanks, Cord you are welcome! -- Cord Beermann [EMAIL PROTECTED] (Privat) ~ ASCII Ribbon Campaign X Say NO to HTML in email and news / \ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpn98290mIWu.pgp Description: PGP signature
Re: How to deal with lintian E: missing shlibs information
hi! :)
On Thu, Dec 21, 2000 at 11:33:59PM +0900, Junichi Uekawa wrote:
Hello,
I'm building a python bindings file with ecasound, and I've decided I'd call
it
python-ecasound just like other python binding packages...
does it provides shared libraries or modules that maybe loaded runtime?
Now, lintian tells me thus :
E: python-ecasound: no-shlibs-control-file
usr/lib/python1.5/site-packages/libpyecasound.so
N:
N: Though the package includes a shared library, the package does not
N: have a shlibs control file. If this is intentional, please contact
N: [EMAIL PROTECTED] about this so that this error gets included
N: in the overrides file for Lintian. (With that, Lintian will ignore
N: this bug in the future.)
N:
What should I do? Put a debian/python-ecasound.shlibs ?
if it is a shared library you should write a
{$PACKAGE_PROVIDING_THE_LIBRARY}.shlibs
in order to let the system know who is providing what. so that in making other
packages
depending on your shared library the others will correctly make them depend on
your
package.
if it is not a shared object (probably it is a plugin or the like) it doesn't
need the shlibs stuff.
What should I put in there.
please read the packaging manual in the developer's corner online, it is a good
thing and you have to feel comfortable with it. :)
What really makes me confused is the fact other python packages do not
seem to have this error generated from lintian, and yet they do not seem
to have the shlibs file either.
do they provide libraries or plugins?
regards,
junichi
--
University: [EMAIL PROTECTED]Netfort: [EMAIL PROTECTED]
dancer, a.k.a. Junichi Uekawa http://www.netfort.gr.jp/~dancer
Dept. of Knowledge Engineering and Computer Science, Doshisha University.
... Long Live Free Software, LIBERTAS OMNI VINCIT.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
--[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
pgpKv2Pw339X7.pgp
Description: PGP signature
Re: Problem building a package
are you using debhelper scripts?
if yes, check the DH_COMPAT variable in debian/rules file.
if it is 1, among other things, the first binary package referred in
debian/control will be searched in debian/tmp. if it is 2, the first
package will be searched in debian/{$PACKAGE_NAME} directory.
the debian/rule anyway says in the make install line to install the
stuff in debian/tmp, ence the misbehavior if DH_COMPAT is set to 1.
i had a problem like this.
On Tue, Dec 19, 2000 at 03:01:09PM +0100, Raphaël HALIMI wrote:
Hi, I'm new to this list so, if I'm out of the subject, please tell me
which list I must use.
i'm trying to build a package from a source tar.gz file. To accomplish
this, I installed the package maint-guide and followed all
instructions in it (installation of new packages, etc etc). Finally,
after some hours spent trying, I had a .deb package. But this is VERY
strange... There's no program in this package. Only the docs. Although
the program compiles and installs (in the tmp dir) good, the content of
debian/tmp/bin and debian/tmp/lib ain't copied i the .deb. The
maintainer's guide tells to run lintian on the package, to see if
there's any error; but even this, I can't do it, because gpg complains
about not finding my secret key and so it dpkg-buildpackage doesn't
build this .changes file. I did run gpg--gen-key
Please, can someone help me ? I think i'm going crazy...
Thanks in advance.
--
Raphaël HALIMI
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
--[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
pgpJf7dUGyqCT.pgp
Description: PGP signature
libtool -rpath: i'm at the start line again
ok, maybe it is better to ask here because i'm still pretty confused by this story about libtool and his damned parameter -rpath. any help appreciated. follows a little explanation, extracted from ld manpage, of what this parameter tells the linker to do: "Add a directory to the runtime library search path." and again "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link". the developer team of libtool made mandatory the use of this parameter, since it was included automatically by libtool in every linker command line. this approach had advantages and drawbacks (which i almost ignore) and in the debian project has been chosen to not admit it. for this reason, until a couple of months ago almost every, if not all, the binaries which worked with shared libraries using libtool had to apply a workarond. lintian had (and still has) a check against this kind of "malformation" in debian binaries and shared libraries. on september, and here i started losing the thread, Marcus Brinkmann posted a message (http://lists.debian.org/debian-devel-announce-0009/msg8.html) in [EMAIL PROTECTED] (now i understand why i didn't see it, i'm not subscribed to this mailing list) in which he said to update to the new release of libtool, which has many problem solved, -rpath problem included (he didn't say that explicitly, but sombody told me). lintian has been someway updated but it still reports the -rpath problem (please, i need to understand which way lintian has been updated. it seems always the same to me) but this time the workarond for -rpath is considered obsolete (i reported the bug #78420 about a reference in the output of lintian to this obsolete and now missing workaround file). btw, Brinkmann said to user libtoolize -f to reconstruct some libtool in the package in order to avoid problems (i have to use also the -c switch since libtoolize make some symlinks that don't like to my debuid). after recompilation, debuild runs lintian that *again* complain about -rpath. please correct me in anywhere i'm wrong. as i understood the solution is in what i wrote above but i don't see it. what i am missing? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libtool -rpath: i'm at the start line again
ok, maybe it is better to ask here because i'm still pretty confused by this story about libtool and his damned parameter -rpath. any help appreciated. follows a little explanation, extracted from ld manpage, of what this parameter tells the linker to do: Add a directory to the runtime library search path. and again The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link. the developer team of libtool made mandatory the use of this parameter, since it was included automatically by libtool in every linker command line. this approach had advantages and drawbacks (which i almost ignore) and in the debian project has been chosen to not admit it. for this reason, until a couple of months ago almost every, if not all, the binaries which worked with shared libraries using libtool had to apply a workarond. lintian had (and still has) a check against this kind of malformation in debian binaries and shared libraries. on september, and here i started losing the thread, Marcus Brinkmann posted a message (http://lists.debian.org/debian-devel-announce-0009/msg8.html) in debian-devel-announce@lists.debian.org (now i understand why i didn't see it, i'm not subscribed to this mailing list) in which he said to update to the new release of libtool, which has many problem solved, -rpath problem included (he didn't say that explicitly, but sombody told me). lintian has been someway updated but it still reports the -rpath problem (please, i need to understand which way lintian has been updated. it seems always the same to me) but this time the workarond for -rpath is considered obsolete (i reported the bug #78420 about a reference in the output of lintian to this obsolete and now missing workaround file). btw, Brinkmann said to user libtoolize -f to reconstruct some libtool in the package in order to avoid problems (i have to use also the -c switch since libtoolize make some symlinks that don't like to my debuid). after recompilation, debuild runs lintian that *again* complain about -rpath. please correct me in anywhere i'm wrong. as i understood the solution is in what i wrote above but i don't see it. what i am missing? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: statoverride
On Thu, Nov 30, 2000 at 04:54:33PM -0500, Ben Collins wrote: Wichert says he will have a postinst script that converts suid.conf over to statoverride format. It seems to me that the best way to convert is to simply remove the calls to suidmanager in your install scripts. If you user debhelper and currently depend on it to add in the suidmanager calls to your postinst scripts, then most likely you wont have to do anything, except rebuild with the new debhelper when it comes around (since I'm guessing it will drop this support, in favor of dpkg's conversion). the problem is not choking the old suidmanager preferences up on upgrade to the new dpkg-statoverride -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpt4fxkr3aXN.pgp Description: PGP signature
Re: Contact?
On Mon, Nov 20, 2000 at 03:53:12PM +, Paul Martin wrote: On Mon, Nov 20, 2000 at 08:05:06AM -0500, stramiello wrote: How long does it take after submitting my info to the webpage until I hear from an AM? Just curious since its been a few weeks... It can take months. Once you've been contacted by your AM, things can happen very quickly, if you're prepared for the questions they are going to ask you. I was lucky (and prepared): from the initial AM contact to the DAM providing me with a login took approximately 52 hours. my AM is a very busy one and now a couple of months are gone since the first contact. i'm still waiting for the "Philosophy and Procedures Check" being checked. as soon as i posted my application i looked around for a package to maintain, it is 15 months (1 year and 3 months) that i maintain it and still i'm not a debian maintainer. in these months i added a couple of new other packages to my arsenal, that's ok. i'm sure that i know how to do some basic packaging... :) so, everybody be happy with actual timelines. (i'm seriously thinking at re-applicating to the nm queue... ) -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Contact?
On Mon, Nov 20, 2000 at 03:53:12PM +, Paul Martin wrote: On Mon, Nov 20, 2000 at 08:05:06AM -0500, stramiello wrote: How long does it take after submitting my info to the webpage until I hear from an AM? Just curious since its been a few weeks... It can take months. Once you've been contacted by your AM, things can happen very quickly, if you're prepared for the questions they are going to ask you. I was lucky (and prepared): from the initial AM contact to the DAM providing me with a login took approximately 52 hours. my AM is a very busy one and now a couple of months are gone since the first contact. i'm still waiting for the Philosophy and Procedures Check being checked. as soon as i posted my application i looked around for a package to maintain, it is 15 months (1 year and 3 months) that i maintain it and still i'm not a debian maintainer. in these months i added a couple of new other packages to my arsenal, that's ok. i'm sure that i know how to do some basic packaging... :) so, everybody be happy with actual timelines. (i'm seriously thinking at re-applicating to the nm queue... ) -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: What to do during the NM wait?
On Wed, Oct 18, 2000 at 10:56:12PM +0100, Julian Gilbey wrote: On Wed, Oct 18, 2000 at 04:45:10PM -0400, Gopal Narayanan wrote: On Wed, Oct 18, 2000 at 10:39:46AM -0500, An Thi-Nguyen Le wrote: In particular, I want to (eventually) adopt the fvwm[1] packages. I have toyed with the idea of contacting the current maintainer offering these packages even though I haven't been contacted by an AM yet but I'm not sure if that's right or wrong. Only even contemplate adopting fvwm if you know or are willing to work hard at learning Xlib. It's a tough package (as I discovered to my cost.) There are a couple of people who have expressed interest, and when I have time to go through my inbox (soon, I really hope, but RL is crazy right now), I will see whether they want it. Do you want me to add you to the list? hi julian! i'm one of that couple of people you talked about. i think you can safely remove me from your list, this code is very hard for me to understand very well. i prefer to keep fewer packages but in a better way. maybe when i'll be a better coder i try it again. thank you anyway :) -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc --[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Accepted ways when upstream author insists on using MANPATH env var?
a worse solution could be to wrap TkMan in a script, passing the
output of /usr/bin/manpath to an environment variable. brrr...
#!/bin/sh
# wrap for TkMan
export MANPATH=`/usr/bin/manpath`
whatever to run tkman
On Fri, Sep 08, 2000 at 08:57:47AM +0300, Shaul Karl wrote:
TkMan author insists on using the MANPATH environment variable.
The bottom line is that
* TkMan used to have a variety of ways to set the MANPATH if it
was not already set. The MANPATH is simple to set, is recognized
on all flavors of UNIX and all man-related tools, is easily
customized, and does everything that these other ways did. It
is now the one and only way to communicate man directories to
TkMan.
He is explaining his position quite throughly but basically I believe it boils
to that he has found this to be the best way to handle different flavors of
UNIX.
This state of affairs contradicts section 3.9 of the policy.
My current solution is to patch the programe with a conditional setting of the
MANPATH:
if {![info exists env(MANPATH)] || [string equal [string trim $env(MANPATH)]
""]} {
set env(MANPATH) [ exec /usr/bin/manpath ];}
What are the acceptable ways to handle similar situations? Is there a better
way other then using /usr/bin/manpath?
--
-- Shaul Karl [EMAIL PROTECTED]
Donate free food to the world's hungry: see http://www.thehungersite.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-[ Domenico Andreoli, aka cavok
--[ get my public gpg key at http://www.freeweb.org/free/cavok/
-[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
PGP signature
Re: Accepted ways when upstream author insists on using MANPATH env var?
a worse solution could be to wrap TkMan in a script, passing the
output of /usr/bin/manpath to an environment variable. brrr...
#!/bin/sh
# wrap for TkMan
export MANPATH=`/usr/bin/manpath`
whatever to run tkman
On Fri, Sep 08, 2000 at 08:57:47AM +0300, Shaul Karl wrote:
TkMan author insists on using the MANPATH environment variable.
The bottom line is that
* TkMan used to have a variety of ways to set the MANPATH if it
was not already set. The MANPATH is simple to set, is recognized
on all flavors of UNIX and all man-related tools, is easily
customized, and does everything that these other ways did. It
is now the one and only way to communicate man directories to
TkMan.
He is explaining his position quite throughly but basically I believe it
boils
to that he has found this to be the best way to handle different flavors of
UNIX.
This state of affairs contradicts section 3.9 of the policy.
My current solution is to patch the programe with a conditional setting of
the
MANPATH:
if {![info exists env(MANPATH)] || [string equal [string trim $env(MANPATH)]
]} {
set env(MANPATH) [ exec /usr/bin/manpath ];}
What are the acceptable ways to handle similar situations? Is there a better
way other then using /usr/bin/manpath?
--
-- Shaul Karl [EMAIL PROTECTED]
Donate free food to the world's hungry: see http://www.thehungersite.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
-[ Domenico Andreoli, aka cavok
--[ get my public gpg key at http://www.freeweb.org/free/cavok/
-[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
pgprsxhD0tDGk.pgp
Description: PGP signature
lintian complains about unknown control files
package i maintain (hping2) now uses debconf to ask a question. in order to make it do this, i had to use debian/config and debian/templates files. everything works very well, but lintian complains about unknown control files referring to debian/config and debian/templates. i obtain these complains both on potato and woody, both of them are completely up to date to today archives. moreover, hping2 source packages generate only a binary package, so for sure i have no messes with control file names. i don't see anything wrong, i follow completely the debconf tutorial written by joey hess. at least i think. btw, now that i think at it, you know debian/config file? yeah, it has the first command line parameter that is configure or reconfigure. the second is the version of the package and it is present only if debian/config happens to be executed by dpkg-reconfigure. is it right to think that if $1==configure = $2= and if $1==reconfigure = $2=some_package_version? in which case i should care about $1 and/or $2? at the moment i completely ignore them, since debconf asks only whether hping2 should be installed as suid or not. -[ Domenico Andreoli, aka cavok ]--[ ICQ: 56447243 --[ get my public gpg key at http://www.freeweb.org/free/cavok/ -[ unix is user friendly. it's just selective about who its friends are... -[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 ]-- pgpwYA0g9ed5j.pgp Description: PGP signature
Re: lintian complains about unknown control files
On Sun, Sep 03, 2000 at 03:51:00PM -0700, Joey Hess wrote: Domenico Andreoli wrote: everything works very well, but lintian complains about unknown control files referring to debian/config and debian/templates. This is becuase lintian is taking a strict interprtation of policy and complaining about all additional files. Yes, it can be argued that using debhelper causes a package to violate policy. Perhaps policy should be fixed.. if i am not wrong, my package is already ok, right? btw, now that i think at it, you know debian/config file? yeah, it has the first command line parameter that is configure or reconfigure. the second is the version of the package and it is present only if debian/config happens to be executed by dpkg-reconfigure. It is? That would be a bug; please file a bug report with a test case. The second parameter is supposed to always be set to the version of the package that is being configured. i misread docs, first parameter is equal to reconfigure only if debian/config is invoked by dpkg-reconfigure. second is always package version. thanks for your fast explainations. :) -[ Domenico Andreoli, aka cavok ]--[ ICQ: 56447243 --[ get my public gpg key at http://www.freeweb.org/free/cavok/ -[ unix is user friendly. it's just selective about who its friends are... -[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 ]-- pgp1zac9MYqFF.pgp Description: PGP signature
Re: Crossposts
On Tue, Aug 01, 2000 at 12:25:36AM +0200, Jens Müller wrote: Is it necessary to cross-post all messages that go to this list??? i think no, otherwise this list would have not much sense. -[ Domenico Andreoli, aka cavok ]--[ ICQ: 56447243 --[ get my public gpg key at http://www.freeweb.org/free/cavok/ -[ unix is user friendly. it's just selective about who its friends are... -[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 ]-- pgp6v7BLoXwGl.pgp Description: PGP signature
300 Multiple Choices
i received the error report in the object from apt-get but i didn't find any information about what does it means. i have a tree like this debian |-potato | |-Packages | |-override | |-curl_6.5.2-1_i386.deb | |-curl-ssl_6.5.2-1_i386.deb | \- ... |-woody \-slink the Packages file in ./debian/potato/ is the output of this command: [debian]$ dpkg-scanpackages potato potato/override potato/Packages override is a plain regular one, here it is: ## start curl optional web curl-ssl optional non-US/main ## end is it possible to understand what is going wrong? thank for your support -[ Domenico Andreoli, aka cavok --[ get my public pgp key at http://www.freeweb.org/free/cavok/ -[ ICQ: 56447243 ]-- ---[ look for DeCSS code in my homepage! pgpj092iKzgXz.pgp Description: PGP signature
frozen/unstable and bug tracking reports
i'm the maintainer of curl and curl-ssl, sponsored by Stephane Bortzmeyer, so i'm not an official developer. just few days after potato went frozen, a new release of curl had been published, this was 6.5.2. this one closes bug #56627 opened for curl. well, i packaged the new release (6.5.2-1) but it could not be put in potato because of it was frozen. neither i fed up Stephane with my silly upgrade, since he is surely more upset by potato than me. now another bug (#63461) has been filled against curl-ssl_6.0_1.1 which is actually in poatato, it is already fixed in 6.5.2-1, which is the last i packed. what i have to do? has it so much sense tu publish a new package for woody, close bugs when potato still has them in? -[ Domenico Andreoli, aka cavok --[ get my public pgp key at http://www.freeweb.org/free/cavok/ -[ ICQ: 56447243 ]-- ---[ look for DeCSS code in my homepage! pgpzPUFSsb33V.pgp Description: PGP signature
who is looking for a sponsor ?
anybody interested in a sponsor? ok, point your browser at: http://www.internatif.org/bortzmeyer/debian/sponsor/ -- -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://www.freeweb.org/free/cavok/ -[ ICQ: 56447243 ]-- ---[ look for DeCSS code in my homepage! pgp0FZ5x7evZK.pgp Description: PGP signature
problem with sections
ok, may be it's time for me to ask help here.
i'm the curl package maintainer, a sponsorized and not a real one i mean.
i've this problem:
i can't figure how to put my package in the right section.
debianized curl is divided in two binaries: curl and curl-ssl.
they conflicts each other and that is fine.
i'd like to put curl in the web section of main whereas curl-ssl
in non-US/main.
i talk about curl now, since that for curl-ssl the procedure is the same.
here is my control file for curl source tree:
Source: curl
Section: web
Priority: optional
Maintainer: Domenico Andreoli [EMAIL PROTECTED]
Standards-Version: 3.1.1
Package: curl
Architecture: any
Conflicts: curl-ssl
Depends: ${shlibs:Depends}
Description: Get a file from an FTP, GOPHER, or HTTP server. (no ssl)
curl is a client to get documents/files from servers, using any of the
supported protocols. The command is designed to work without user
interaction or any kind of interactivity.
.
curl offers a busload of useful tricks like proxy support, user
authentication, ftp upload, HTTP post, file transfer resume and more.
.
Note: this version is compiled without SSL support.
EOF
it looks fine, doesn't it?
here is that for wget (i took it as example):
Source: wget
Section: web
Priority: optional
Maintainer: Nicolás Lichtmaier [EMAIL PROTECTED]
Standards-Version: 3.0.1
Package: wget
Architecture: any
Depends: ${shlibs:Depends}
Description: utility to retrieve files from the WWW via HTTP and FTP
Wget [formerly known as Geturl] is a freely available network utility
to retrieve files from the World Wide Web using HTTP and FTP, the two
most widely used Internet protocols. It works non-interactively, thus
enabling work in the background, after having logged off.
.
The recursive retrieval of HTML pages, as well as FTP sites is
supported -- you can use Wget to make mirrors of archives and home
pages, or traverse the web like a WWW robot (Wget understands
/robots.txt).
EOF
ok. the problem is that after a dpkg-buildpackage -rfakeroot -us -uc
wget package comes with right section whereas curl comes with no section
at all! same problem with curl-ssl.
now i want to understund why this is happening.
could anybody help me with this mess? what is wrong?
thaks all.
happy new y2k!!! :)
-[ Domenico Andreoli, aka cavok [EMAIL PROTECTED]
--[ get my public pgp key at http://www.freeweb.org/free/cavok/
-[ ICQ: 56447243
pgpplY7fyoqEY.pgp
Description: PGP signature
Re: multiple binary packages (again)
On Sat, 14 Aug 1999, Gopal Narayanan wrote: Curl is already packaged and available for potato. If you are packaging this for your own edification, you can take a look at this package to see how it was done. http://www.debian.org/Packages/unstable/non-us/curl.html i know, i took over the actual maintainer, Leon Breedt. i'm not a debian devel yet... he did only ssl version, i want to do both. by the way, upstream maintainer says curl-ssl was based upon ssleay. now he wants change to openssl. actually curl can be compiled with both, in the future support will be granted only for openssl. i can't compile it neither with ssleay nor openssl. i have to install libssl package. i'm not understanding the point. openssl package is installed but dpkg-shlibdeps says my binary is dynamically linked against libssl again. what a mess with theese libraries, shouldn't be them all mutually exclusive? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
Re: package uploading
On 14 Aug 1999, Falk Hueffner wrote: There are auto-build deamons for all architectures now. So, in theory, it should suffice to upload the source only. In practice, developers usually upload the source and the binary package for their favourite architecture, because this way they can test the package first, and also they can simply upload all stuff generated by the debuild script. great! debuild is new for me, let me print its man page... anyway, i'm not a debian devel. somebody has to sponsor me for curl upload -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
Re: multiple binary packages (again)
On Sat, 14 Aug 1999, Raphael Hertzog wrote: Why don't take a look a other sources building many packages ? Vim was listed as an example ... you may want to take a look at perl-5.005 too. That's the best source of information in general, look what has already been done. i took apache-1.3.3-7, it seems having same my matters with ssl Apart from that, isn't there a non-US problem with the SSL support ? Take care not to install in main something that could not be exported by US residents. right, i have to break source in two anyway. i can't put source in main distribution that require some non-US packages, can i? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
package uploading
i didn't understand how to upload packages. i mean, debian developers have to upload source packages only? will source be compiled on debian systems in order to do binaries packages for distribution? or have both source and binaries packages to be uploaded? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
multiple binary packages (again)
i'm trying to package curl. curl is tool to download anything from the net in all sort of ways (http, ftp, gopher, https). it comes also with ssl support, i can tell it to compile ssl support by a switch after ./configure. in order to get both version i have to configure/make sources (for plain version), save somewhere plain binary and clean reconfigure/remake all (for ssl flavour). well, multiple binary packages support goes well when with a build you get all you need to make all binary packages. debstd (i hate it, it is stupid) wants to debianize all packages you are building *at once*. so when i build the first binary package (say the plain one) it tryes to debianize also the ssl one (which i have not even built yet!). OT i think debstd would be more friendly if it could care about a package at time, wouldn't it? /OT moreover, dpkg-buildpackage wants to do make build and then make binary. i can build a curl flavour at time. to do a binary package i must to have just built that flavour. i can't make both of them and then pack them. unless i have to copy all the source tree somewhere and proceed to parallel work. hmmm... have i to do a source packages for each flawour of curl? it sounds dull to me. any help is welcome to me thanks -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://cavok.freeweb.org
