fatal: Unable to create '/srv/scratch/qa.debian.org/vcswatch/.../shallow.lock': No space left on device
Hi, I'm seeing this error in the "action needed" section of DPT [0]: Failed to analyze the VCS repository. Please troubleshoot and fix the issue. vcswatch reports that there is an error with this package's VCS, or the debian/changelog file inside it. Please check the error shown below and try to fix it. You might have to update the VCS URL in the debian/control file to point to the correct repository. fatal: Unable to create '/srv/scratch/qa.debian.org/vcswatch/g/golang-github-flowstack-go-jsonschema/shallow.lock': No space left on device Some machine needs maintenance due to a full disk. Thanks, Dom [0] https://tracker.debian.org/pkg/golang-github-flowstack-go-jsonschema -- 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#1014634: ITP: golang-github-iovisor-gobpf -- Go bindings for creating BPF programs.
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-github-iovisor-gobpf Version : 0.2.0-1 Upstream Author : IO Visor Project * URL : https://github.com/iovisor/gobpf * License : Apache-2.0 Programming Lang: Go Description : Go bindings for creating BPF programs. This repository provides go bindings for the bcc framework as well as low-level routines to load and use eBPF programs from .elf files.
Bug#1014406: ITP: oci-seccomp-bpf-hook -- OCI hook to trace syscalls and generate a seccomp profile
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: oci-seccomp-bpf-hook Version : 1.2.5-1 Upstream Author : Valentin Rothberg, Daniel J. Walsh, et al. * URL : https://github.com/containers/oci-seccomp-bpf-hook * License : Apache-2.0 Programming Lang: Go Description : OCI hook to trace syscalls and generate a seccomp profile This project provides an OCI hook to generate seccomp profiles by tracing the syscalls made by the container. The generated profile would allow all the syscalls made and deny every other syscall. -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-k8s-apimachinery Version : 1.25.0~alpha0-1 Upstream Author : Kubernetes * URL : https://github.com/kubernetes/apimachinery * License : Apache-2.0 Programming Lang: Go Description : Handle Kubernetes-like API objects. This library is a shared dependency for servers and clients to work with Kubernetes API infrastructure without direct type dependencies. Its first consumers are k8s.io/kubernetes, k8s.io/client-go, and k8s.io/apiserver.
Bug#1012317: ITP: golang-github-flowstack-go-jsonschema -- Go JSON Schema parser and validator
Package: wnpp Severity: wishlist Owner: Domenico Andreoli * Package name: golang-github-flowstack-go-jsonschema Version : 0.1.1-1 Upstream Author : FlowStack * URL : https://github.com/flowstack/go-jsonschema * License : Expat Programming Lang: Go Description : Go JSON Schema parser and validator The very nice gojsonschema was missing some features and we needed some internal functionality, that was hard to build on top of gojsonschema. . This module uses the excellent jsonparser, which is wy faster than Go's builtin parser.
Bug#1008492: ITP: jh7100-bootloader-recovery -- StarFive JH7100 recovery bootloader
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jh7100-bootloader-recovery Version : 2021-07-14 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/bootloader_recovery * License : GPL Programming Lang: C Description : StarFive JH7100 recovery bootloader This firmware brings up the board enough to program all the boot stages onto the boot flash. It recovers an otherwise unbootable system.
Bug#1008475: ITP: jh71xx-tools -- StarFive JH71xx bootloader recovery and updater tool
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jh71xx-tools Version : 2021-07-16 Upstream Author : Kali Prasad * URL : https://github.com/kprasadvnsi/JH71xx-tools * License : MIT Programming Lang: C Description : StarFive JH71xx bootloader recovery and updater tool This utility is used to download the bootloader recovery firmware, the second stage bootloader and the ddrinit firmware to the CPU via UART. It uses the xmodem protocol over UART, as expected by the JH71xx when the boot flash is blank.
Bug#1008473: ITP: jh7100-ddrinit -- StarFive JH7100 DDR initialization stage
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jh7100-ddrinit Version : 2021-11-02 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/JH7100_ddrinit * License : GPL Programming Lang: C Description : StarFive JH7100 DDR initialization stage This firmware is loaded early by the boot loader, its purpose is to configure the DDR controller before any later stage is executed. Depending on your board, it might be needed to build a bootable media or just be programmed in an internal flash.
Bug#1008472: ITP: jh7100-second-boot -- StarFive JH7100 boot loader
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jh7100-second-boot Version : 2021-11-02 Upstream Author : StarFive Tech. * URL : https://github.com/starfive-tech/JH7100_secondBoot * License : GPL Programming Lang: C Description : StarFive JH7100 boot loader This is the very first piece of software loaded by the CPU during boot. Its purpose is to prepare the HW for the execution of OpenSBI and all the subsequent stages of the boot, like U-Boot and Linux. Depending on your board, it might be needed to build a bootable media or just be programmed in an internal flash.
Re: Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices
On Sun, Mar 13, 2022 at 09:47:01PM +0100, Philip Rinn wrote: > On 13.03.22 at 18:47, Domenico Andreoli wrote: > > Now, wouldn't be nice to have the latest version uploaded to main and > > the renamed alternative to NEW? > > Absolutely, that's what I just did - at least the first part. Uploading it as > solo1-cli will follow soon. Any plan of packaging solo2-cli? Dom -- 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
Re: Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices
On Sun, Mar 13, 2022 at 05:55:19PM +0100, Philip Rinn wrote: > Hi Domenico, Hey Philip, > > it's already packaged, see: https://tracker.debian.org/pkg/solo-python. Excellent, one thing less in my TODO. Let's immediately close thin bug. Thanks for packaging it. > I plan to transition it to the new upstream name soon. Now, wouldn't be nice to have the latest version uploaded to main and the renamed alternative to NEW? > > Best regards > Philip Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Bug#1007202: ITP: solo1 -- Python module and CLI for SoloKeys Solo 1 devices
Package: wnpp Severity: wishlist Owner: Domenico Andreoli X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: solo1 Version : 0.1.1 Upstream Author : he...@solokeys.com * URL : https://github.com/solokeys/solo1-cli * License : Apache 2.0 and MIT Programming Lang: Python Description : Python module and CLI for SoloKeys Solo 1 devices With this package you get a command-line interface to manage your SoloKeys and a Python module to interface them with your applications. Some of the operations you can do: - set or change the PIN - read the firmware version - update the firmware - wipe all your credentials - verify whether your device is a Solo Secure or Solo Hacker
Re: Mass bugs filing: autopkgtest must be marked superficial
On Sun, Nov 08, 2020 at 10:28:54PM +, Sudip Mukherjee wrote: > Hi All, Hi, > This is a new list for the autopkgtest superficial test. > > If the test done in the autopkgtest does not provide significant test > coverage then it should be marked with "Restrictions: superficial". > Ref: > https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst > > Examples of tests which are not significant includes (its not a complete > list): > > 1) Executing the binary to check version > Test-Command: foo -v > Test-Command: foo -V > Test-Command: foo --version > > 2) Executing the binary to check help (foo -h) > Test-Command: foo -h > Test-Command: foo --help > > 3) A Python or Perl library runs import foo or require Foo; but does > not attempt to use the library beyond that. > Test-Command: python3 -c "import foo" > In dwarves-dfsg's case, a suite to analyzes ELF binaries, I run pahole on itself. I don't validate the output and certainly do not exaust the use cases of that or any other tool distributed in the same package. I consider it a superficial test. Do you agree? Thanks, Domenico -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Re: Hosting the original youtube-dl sources on salsa?
On Thu, Oct 29, 2020 at 04:59:53PM -0300, Rogério Brito wrote:
> Dear people,
>
> As many of you may know, the RIAA issued a resquest for GitHub to take down
> the youtube-dl repository.
>
> The tree had some fixes that were *not* in the latest release that I
> uploaded a few days ago (I am the maintainer of youtube-dl in Debian, just
> to make things clear).
>
> Since the tree was taken down (and, to boot, of the 18 forks listed in the
> takedown request, mine was explicitly listed), I fear that me uploading the
> lastest tree to GitHub is asking for trouble.
>
> Given this situation, can I upload a backup of youtube-dl to salsa under my
> user account? I already maintain the packaging of youtube-dl in a different
> repository that is both on GitHub and on salsa. Should I take it down from
> salsa?
>
First things first, we need to have many copies of that and make it
available it all over the net.
Do you have a complete git repo that can be cloned?
> If these are not the appropriate mailing lists to send this to, please point
> me to better places. I was in a hurry and I decided to send this as soon as
> I found out places that seemed suitable.
>
>
>
> Thanks for any help and support,
>
> Rogério Brito.
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>
--
rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
Re: Lenovo and forced labor [was: Re: Lenovo discount portal update (and a few other things)]
On Thu, Sep 03, 2020 at 10:47:06AM +0200, Tomas Pospisek wrote: > On 02.09.20 15:08, Mark Pearson wrote: > > Hi Debian developers, > > > > Following on from DebConf 2020 (which I thoroughly enjoyed - thank you!) > > the Lenovo portal that was announced is now available: > > > > US: http://www.lenovo.com/us/en/Linux > > Canada: http://www.lenovo.com/ca/en/linuxca > > I think before jumping on this offer, one should consider this: > https://www.aspi.org.au/report/uyghurs-sale > > Lenovo is by far not the only company producing laptops with forced > labor involved, however they have not - as of today - as far as I can > see - cared to comment on those report at all: > > * they have neither denied nor ack'ed it > * and they haven't said either that they'd no longer use forced labor to > produce their wares > > I'd conclude from that, that Lenovo still is, will be, and is not > planing to stop using forced labor to produce those laptops. > > I'm not sure there are alternatives: I have not researched them > intensively yet - I am currently in need of a new laptop too, so I'll > have to look around whether there are other brands that do not rely on > companies that employ forced labor. Pointers welcome. You may want to consider System76 [0] and Purism [1]. They are not in the force labor lists pointed in this thread, maybe they are ethically better than the others. Dom [0] https://system76.com [1] https://puri.sm -- 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
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
On August 1, 2019 7:10:14 PM UTC, Bastian Blank wrote: >On Thu, Aug 01, 2019 at 08:21:31PM +0200, Inaki Malerba wrote: >> On 27/7/19 09:40, Bastian Blank wrote: >> > The setting is per project, so it is available. For now I say that >> > changing this globally is too disruptive. >> Of course it's a disruptive change, but what is the purpose of Salsa? > >It is a project management platform. > >> I think it's a tool *for* Debian and Debian Developers. Most of the >> users surely will prefer that the default path for the CI >configuration >> on Debian projects is a Debian compatible path. Maybe we could open a >> thread to discuss this on d-devel, if some day we have the feature to >> make this change, but it's is not even planned yet. > >Maybe someone can come up with code to see how it works. > >Questions to be answered: >- Is the setting only a default applied to new projects? >- If yes, how do you inform users that a new project with > /.gitlab-ci.yml will not work? >- If no, how do you inform users that an existing project with > /.gitlab-ci.yml will stop working? I don't like any of these questions, I would prefer not having to answer to them. My instinct for the most predictable and least surprising solution is to leave /.gitlab-ci.yml as default, per-project configurable and _clonable_ so that clones would simply inherit the original setting whatever it is. > >> Anyway, I think the best alternative for making this change less >> disruptive is going to be group-level definitions[0] of this kind of >> configurations. > >Maybe it would be better to fix stuff to work with /.gitlab-ci.yml than >trying to hack around global settings? Salsa is not Debian-only, we >already have several upstream stuff on it. > Having a salsa global default different from the gitlab one is just surprising indeed, would "patch in" a solution for a quite specific case (plain debian package with default salsa-ci.yml) and would still leave diverging settings dead in the water at first clone. I did not follow most closely this thread, is setting cloning being explored already? >Regards, >Bastian Regards, Domenico
Re: Salsa CI news
On February 26, 2019 5:32:57 PM UTC, Inaki Malerba wrote: >Hi Domenico! > >On 26/2/19 14:17, Domenico Andreoli wrote: >>> We also introduced a way to monitor the pipeline's usage. >>> prittiau.debian.net is a simple influxdb + grafana which shows some >>> stats about the projects using the Salsa CI pipeline. You're welcome >to >>> log in with your salsa account. >> I'm loggiagn in right now, Salsa asks for the following >authorization: >> >> An application called Gitlab is requesting access to your GitLab >> account. This application was created by Iñaki Malerba. Please note >> that this application is not provided by GitLab and you should >verify >> its authenticity before allowing access. >> >> I find slightly confusing that "An application called Gitlab is >> requesting access to your GitLab account". Maybe you could choose a >> different name? > >That's because Grafana uses Gitlab Oauth2 authentication[0]. I only >created a Oauth application at Salsa and everything else is on Grafana. If I got it right, according to Gitlab docs [0], it's possible to set an arbitrary name for the App you want to configure. >> Thanks for all the good work! :) > >My pleasure! thanks, Domenico [0] https://docs.gitlab.com/ce/integration/oauth_provider.html
Re: Salsa CI news
On Mon, Feb 25, 2019 at 11:19:35AM -0300, Inaki Malerba wrote: > Hi everyone ! Hi Inaki, [...] > We also introduced a way to monitor the pipeline's usage. > prittiau.debian.net is a simple influxdb + grafana which shows some > stats about the projects using the Salsa CI pipeline. You're welcome to > log in with your salsa account. I'm loggiagn in right now, Salsa asks for the following authorization: An application called Gitlab is requesting access to your GitLab account. This application was created by Iñaki Malerba. Please note that this application is not provided by GitLab and you should verify its authenticity before allowing access. I find slightly confusing that "An application called Gitlab is requesting access to your GitLab account". Maybe you could choose a different name? > If you have any question, you can find us on #salsaci at OFTC. Thanks for all the good work! :) Regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 signature.asc Description: PGP signature
Review of dwarves 1.12-1 (and sponsoring)
Hi all, after some ~7 years of inactivty I've been able to put a new upstream release of dwarves together. It's at https://salsa.d.o/debian/dwarves. It has some build reproducibility issue, I'll look at that later. I'll also go throught the open bugs, they are quite aged and deserve to be closed asap. Aside from these issues, it's my first work in the age of >=2048 bits key, Salsa and gbp. I'm sure some expert eye can find something worth improving, please give it a glance. In the meanwhile that I resurrect my old 1024 bits key, sign the new one and also get some signatures I might have somewhere, I need a sponsor to upload this package. Any volunteer? Thanks for all the help. Kind regards, Domenico -- 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
Re: usrmerge -- plan B?
On November 20, 2018 9:16:17 PM UTC, Adam Borowski wrote: >Hi! Hi, >Thus, it seems to me that the plan A for usrmerge has serious downsides for >dubious benefits. What about the plan B I described above? My preferred plan B is the one allowing to release Buster on time with most confidence. It's for our users, if we mess up with them the show is over. thanks, Domenico
Re: Q: secure boot
On November 6, 2018 1:14:03 AM UTC, Paul Wise wrote: >So, really the only reason to support Secure Boot is to avoid users >having to turn Secure Boot off in their BIOS and avoid having to >document how to do that on every firmware implementation that is being >shipped on new hardware. I think it is definitely worth the effort to >do this to avoid turning people away to other distros. I'm booting Debian from an external ssd on a locked down laptop, where I cannot disable the secure boot. I had to install the shim of ubuntu. I would definitively prefer to use the Debian one, the install phase would be way easier and I could even decide to install to the internal drive. thanks, Domenico
Re: Introducing codesearch.debian.net, a regexp code search engine
On Tue, Nov 06, 2012 at 07:05:43PM +0100, Michael Stapelberg wrote: > Hi, Hi! > I hereby announce a new Debian project: Debian Code Search. > > Debian Code Search is a search engine for program source code within > Debian. > > It allows you to search all ??? 17000 source packages, > containing 130 GiB of FLOSS source code (including Debian > packaging) with regular expressions. cool :) > You can use the search engine at http://codesearch.debian.net/ nice > I hope you find it useful and would love to hear your feedback. yes, I think it is. it's an enabler kind of tool, people can study the code in new ways and it has applications also in the security field. if you consider that Debian is one of the more extended (and regularly used) collections of software, I'm sure it will be the joy of many :) cheers, Domenico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106215213.GA20829@glitch
Re: Can you believe it? The Debian website has a new layout!
On Sun, Feb 6, 2011 at 2:54 AM, Martin Zobel-Helas wrote: > Hi, Hi! > After a www sprint in December[2][3], David, Francesca, Gerfried and > Kåre spent the last days working nearly 24x7 on the website without much > sleep, to finish the self-set goal of releasing the website's new layout > with the release of Debian Squeeze. I think the project owes them a > really big "Thank you". really amazing :) Thanks to everybody that contributed to this major site overhaul. ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik+p+7uh4phnvfynyyhtuhyxutxde-px9kvm...@mail.gmail.com
Re: Bug#488389: ITP: libv4l -- Transparent conversion layer for V4L devices
On Sat, Jun 28, 2008 at 05:25:13PM +0200, Romain Beauxis wrote: > Package: wnpp > Severity: wishlist > Owner: Romain Beauxis <[EMAIL PROTECTED]> > > > * Package name: libv4l > Version : 0.2 > Upstream Author : Hans de Goede <[EMAIL PROTECTED]> > * URL : http://people.atrpms.net/~hdegoede/ > * License : LGPL > Programming Lang: C > Description : Transparent conversion layer for V4L devices It looks like you issued this ITP before having checked WNPP, please look at #488117. cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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]
Bug#488117: ITP: libv4l -- Thin abstraction layer on top of video4linux2 devices
Package: wnpp Severity: wishlist Owner: Domenico Andreoli <[EMAIL PROTECTED]> * Package name: libv4l Version : 0.1 Upstream Author : Hans de Goede <[EMAIL PROTECTED]> * URL : http://people.atrpms.net/~hdegoede/ * License : LGPL Programming Lang: C Description : Thin abstraction layer on top of video4linux2 devices The purpose of this (thin) layer is to make it easy for application writers to support a wide variety of devices without having to write seperate code for different devices in the same class. cheers, Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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 packages blocked for the poppler, c-ares and ffmpeg transitions
On Thu, Jun 12, 2008 at 07:20:31PM +0200, Adeodato Simó wrote: > Hello. Hi, > Domenico Andreoli <[EMAIL PROTECTED]> >curl latest upload of curl dropped c-ares support because of its problems with IPv6. why do you consider it for this transition? not that I plan to do many uploads more... cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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]
Bug#481074: O: pycurl -- Python bindings to libcurl
Package: wnpp Severity: normal I intend to orphan the pycurl package. It is an easy package so it may be indicated for newcomers. The package description is: This module provides the Python bindings to libcurl. Please refer to the libcurl documentation available in libcurl4-gnutls-dev Debian package. . NOTE: the SSL support is provided by GnuTLS. . Homepage: http://pycurl.sourceforge.net cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: Mail headers for automated package maintenance emails
On Mon, May 12, 2008 at 01:44:24PM +0200, Raphael Hertzog wrote: > On Mon, 12 May 2008, Domenico Andreoli wrote: > > > Afaiui dehs *only* sends emails to [EMAIL PROTECTED], > > > and the question was whether the pts only adds the header to e-mails > > > generated by its own scripts or also to stuff received by mail. (I > > > have no idea whether this even a correct dichotomy) > > > > What about spam sent to [EMAIL PROTECTED] Will it get > > these headers too? > > The PTS only accepts mails from some trusted source so direct spam won't > get forwarded. However spams forwarded by the BTS to the PTS will of > course also get those headers... Indeed my test message bounced.. not that I did not trust you :p Thank you, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: Mail headers for automated package maintenance emails
On Sun, May 11, 2008 at 09:56:46AM +0200, Andreas Metzler wrote: > Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > > On Sunday 11 May 2008 00:56, Raphael Geissert wrote: > >> Also for messages coming from other sources, i.e. dehs? > > > Yes, the idea is that such mails have uniform headers. There are no "other" > > sources: it works best if every tool that sends automated mails to Debian > > package maintainers uses those headers. > > >> Just want to know if I have to make dehs add those headers. > > > "have to" sounds like it's a great ordeal ;-) But yes, please. > > Afaiui dehs *only* sends emails to [EMAIL PROTECTED], > and the question was whether the pts only adds the header to e-mails > generated by its own scripts or also to stuff received by mail. (I > have no idea whether this even a correct dichotomy) What about spam sent to [EMAIL PROTECTED] Will it get these headers too? cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, May 03, 2008 at 12:15:39AM -0500, Steve M. Robbins wrote: > On Tue, Apr 29, 2008 at 01:14:45PM +0200, Domenico Andreoli wrote: > > On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: > > > > > > In contrast, the alternative strategy of having all the libfoo-dev > > > (1.34.1) packages conflict with libfoo1.35.0-dev packages has just a > > > single negative: that you can't develop simultaneously with 1.34.1 and > > > 1.35.0. On the positive side, however, you can install the 1.35 -devs > > > and the existing build scripts will work because the include path and > > > the simplified link library names are preserved. > > > > > > So unless anyone (Domenico?) has a strong preference for the > > > first option, I'm planning to pursue the second. > > > > second option, absolutely. > > Good. I'm planning to assume that the 1.35.x releases are all > approximately API-compatible, so I'm naming the packages > libboost-foo1.35-dev. Any objection to that? > > > My headache now is that there are 13 -dev packages in Boost. One > (libboost1.35-dev) contains 60+ header-only libraries, while the > others each contain 1 library that happens to build a shared object. > > This overhead creates a nonnegligible amount of complexity and > generates bugs (e.g. #457654, #478782). Is there any value to this > granularity? I can't see any. If there are no objections, I'm > leaning towards collapsing all the -dev packages into libboost1.35-dev > -- and rolling bcp into it, as well. I'll probably keep > libboost-python1.35-dev separate (with pyste rolled into it). > > Your thoughts? please, proceed. ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: > > In contrast, the alternative strategy of having all the libfoo-dev > (1.34.1) packages conflict with libfoo1.35.0-dev packages has just a > single negative: that you can't develop simultaneously with 1.34.1 and > 1.35.0. On the positive side, however, you can install the 1.35 -devs > and the existing build scripts will work because the include path and > the simplified link library names are preserved. > > So unless anyone (Domenico?) has a strong preference for the > first option, I'm planning to pursue the second. second option, absolutely. we (I) do not want boost to proliferate in the archive, one version is already demanding for free-time developers. this is only a trick to ease transitions and include newer versions also in late release cycles like current one. cheers, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: [pkg-boost-devel] Bug#473752: Bug#473752: Boost 1.35 has been released
Hi, On Fri, Apr 11, 2008 at 04:13:05PM -0500, Steve M. Robbins wrote: > On Fri, Apr 11, 2008 at 03:13:15PM -0400, Joshua Judson Rosen wrote: > > > > If you guys need some help, I can try updating the packaging for 1.35. > > Packaging is not the issue, however. I think I can do that over the > weekend. The real issue is whether it can be uploaded this close to a > freeze; for example, does it break any existing reverse dependencies? > c.f. http://lists.debian.org/debian-devel/2008/03/msg00930.html > > So, assuming I can produce the packages, what would help is to have > volunteers to test build all the things that build-depend on boost. I think new and separate boost-1.35 package is the best option we have: 1. It may be uploaded now and released with lenny without touching any reverse dependency 2. Never more huge transitions, reverse dependencies take 1.35 as they like 3. At the right time 1.34.x is pulled out the archive and all the broken rdepends get a RC bug 4. This may be repeated for any X and X+1 release of Boost, I hope only for two releases at the same time ;) 5. X+1 packages may be uploaded well before the release, to let people use and test also the pre-releases I could make sush package but I need the point about the SVN repository. Steve, I saw the transition of boost-jam to merge-upstream-mode, which are your plans for boost? cheers, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: Testing parallel builds
On Mon, Oct 08, 2007 at 08:21:22AM -0400, Daniel Schepler wrote: > On Monday 08 October 2007 07:50:58 am Domenico Andreoli wrote: > > > > in the latter case, is there any conventional way to parse > > DEB_BUILD_OPTIONS? last time i read about it there were a couple of ways > > both having dark sides... ah.. BTW google is not able to provide me any > > documentation of DEB_BUILD_OPTIONS. where is it documented? > > It's documented in Debian policy, but parallel hasn't been added there yet. > I > think the new dpkg-buildpackage -j passes > DEB_BUILD_OPTIONS="parallel=". yes, it is in section 10.1. i was hoping some more documentation/use was available. for instance, how one is supposed to set this variable? i now know dpkg-buildpackage -jX sets it. what about other switches? thanks, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: Testing parallel builds
On Mon, Oct 08, 2007 at 06:53:05AM -0400, Daniel Schepler wrote: > Inspired by today's new upload of dpkg, I'm going to try doing a rebuild of > the archive using "dpkg-buildpackage -j3" and submit bugs as I find them. > The bugs will be wishlist for now, and I'll assign usertag > [EMAIL PROTECTED]:ftbfs-parallel to those bug reports for those > interested in tracking the issue. hmm... i was just trying to understand how to enhance my packges for parallel build. (BTW how do you rebuild the whole archive?) if i got it right, those packages built using make & co should not need any modification, while others (eg boost) which use other build systems (eg bjam) may need some more work. in the latter case, is there any conventional way to parse DEB_BUILD_OPTIONS? last time i read about it there were a couple of ways both having dark sides... ah.. BTW google is not able to provide me any documentation of DEB_BUILD_OPTIONS. where is it documented? Regards, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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]
Bug#436522: ITP: dwarves -- Advanced DWARF utilities
Package: wnpp Severity: wishlist Owner: Domenico Andreoli <[EMAIL PROTECTED]> * Package name: dwarves Version : 1.0 Upstream Author : Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> * URL : http://oops.ghostprotocols.net:81/blog * License : GPL Programming Lang: C Description : Advanced DWARF utilities Tools that use the DWARF debugging information inserted in ELF binaries by compilers such as GCC, used by well known debuggers such as GDB, and more recent ones such as systemtap. Utilities in the dwarves suite include: - pahole: finds alignment holes in structs and classes in languages such as C/C++, CPU cacheline alignment. Helps repack those structures to achieve more cache hits. - codiff: a diff like tool to compare the effects changes in source code generate on the resulting binaries - pfunct: that can be used to find all sorts of information about functions, inlines, etc. -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: curl dependency problem in unstable
On Mon, Jun 25, 2007 at 03:35:26PM +0700, [EMAIL PROTECTED] wrote: > Hi Domenico, hi, > I want to upgrade, but I think these conditions make it a no-go for me: > > - libcurl3-gnutls Conflicts: libcurl4-gnutls > - openoffice.org-core Depends: libcurl4-gnutls probably you are a amd64 or powerpc user, where the fixed openoffice.org-core is still not available. you still have to wait a little, sorry :/ ciao, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: curl dependency problem in unstable
On Mon, Jun 25, 2007 at 02:07:05PM +0700, [EMAIL PROTECTED] wrote: > Hi all. hi, > I'm having this problem in unstable for a week now: this should start settling down... > Anyone has an idea how to resolve this? > thanks in advance. all the packages involved in your conflict have a fixed version available. you should simply upgrade them all. regards, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: Bug#422137: ITP: 09F911029D74E35BD84156C5635688C0 -- l33t h4x0r numb3r
On Sat, May 05, 2007 at 02:47:03PM +0200, Evgeni Golov wrote: > On Sat, 5 May 2007 14:34:15 +0200 Adrian von Bidder wrote: > > > On Friday 04 May 2007 20.52:07 Josselin Mouette wrote: > > > > > Don't forget the GUI tools: > > > x09F911029D74E35BD84156C5635688C0 > > > gnome-09F911029D74E35BD84156C5635688C0 > > > k09F911029D74E35BD84156C5635688C0 > > > > You forgot to make Gürkan and a few others happy: > > 09F911029D74E35BD84156C5635688C0.app > > As x09F911029D74E35BD84156C5635688C0 is a generic X11-tool, we need > some nice Xfce stuff for lib09F911029D74E35BD84156C5635688C0 too: > xfce4-09F911029D74E35BD84156C5635688C0-plugin - xfce panel plugin > haggard - thunar style tool for using 09F911029D74E35BD84156C5635688C0 > > And well, you all forgot scripts/plugins for the IM-clients: > gaim-09F911029D74E35BD84156C5635688C0 > gajim-09F911029D74E35BD84156C5635688C0 > xchat-09F911029D74E35BD84156C5635688C0 > irssi-script-09F911029D74E35BD84156C5635688C0 > (and others...) ehi... i want it translated to italin also!! ciao domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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: long double change on alpha, powerpc, sparc, s390
On Fri, Apr 27, 2007 at 02:26:43AM +0200, Matthias Klose wrote: > As mentioned in [1] the long double data type did change from a 64bit > representation to a 128bit representation on the alpha, powerpc, > sparc, s390 targets with glibc-2.5 and gcc-4.1 (4.1.2). To allow sush glibc and gcc-4.q are those already in unstable? so, as soon boost 1.34.0 is released adn uploaded, it will already be on the right side of the transition, won't it? regards domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/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-reconfigure and postinst
On Wed, Jul 05, 2006 at 02:35:44AM -0500, Gerfried Fuchs wrote:
> Hi!
hi,
> I am having a problem, and I guess I might not be the only one who
> might stumble into it. When one wants to do something in new installs
> of the package, they usually check for $2 != "" in the postinst and put
> the stuff in there. So far, so good, and policy friendly because you
> might not create ill side effects about user expectations to no changes
> during upgrades.
this is what i do in the postinst of libapache-mod-ssl package:
# we do not want to bother the user with useless questions at install time
if [ "$1" = "reconfigure" ] || [ "${DEBCONF_RECONFIGURE}" = "1" ]; then
mod-ssl-makecert
fi
this is documented in debconf-devel manpage.
cheers
domenico
-[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~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: Why does doc packages need to contain gzipped files?
On Sat, Jun 24, 2006 at 11:45:00AM +0200, Preben Randhol wrote: > Hi > > I have to my annoyance noticed that several of the doc packages > (especially development packages) contains files that are gzipped. That > is either example source files or pdfs etc... > > My point is that if I choose to install a doc packages I intend to use > it frequently and would therefore like that it is user friendly rather > than that one has squeezed some few kilobytes out by gzipping files. If > I don't need the package anymore I can uninstall it to save the space. > > When it comes to Changelog or other files that are included in all > packages (not only doc packages) it is fine that they are gzipped. I'm > only talking about the pure doc packages. i completely agree with you. i find very annoying to have to gunzip stuff from docs. disk space i cheap. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: sending debian-private postings to gmail
On 5/24/06, Ian Jackson <[EMAIL PROTECTED]> wrote: However, it has come to my attention that at least one developer appears to be reading debian-private at their gmail account. doh! i have been caught :) it's nice to have your personal gobal & searchable mailing list archive, where you can really find anything you have ever received. sorry, i already switched to a safer address, sob.. ciao dom -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: gcc 4.1 or not
On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote: > Hi, hi, > there were some requests, e.g. by Martin Michlmayr to the release team > whether we could switch gcc to 4.1 or not for etch. As we're heading to what about the transition to python 2.4? is it going to start or etch is going to ship with 2.3? cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
i'm still seeing archived bugs
hi, why i'm still seeing lots of archived bugs in my packages? hmm.. also the http://www.debian.org/Bugs/ form does not work correctly. please, what am i doing wrong? i'm accessing the logs with the following url: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=curl thank you domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: libcurl3-dev's reverse Build-Depends
On Wed, Oct 19, 2005 at 03:24:15AM -0700, Steve Langasek wrote: > On Wed, Oct 19, 2005 at 10:03:14AM +0200, Domenico Andreoli wrote: > > On Wed, Oct 19, 2005 at 09:24:42AM +0200, Daniel Schepler wrote: > > > Since libcurl3-dev was removed from unstable, suddenly a lot of packages > > > are > > > now FTBFS because their Build-Depends on libcurl3-dev cannot be > > > satisfied. > > > Would you consider providing a transition libcurl3-dev package for now, > > > or > > > making libcurl3-openssl-dev provide libcurl3-dev? -- Unless it's your > > > intention to force all maintainers to choose explicitly between the > > > openssl > > > and gnutls versions immediately, in which case there should be a mass bug > > > filing. > > > i'd like to force rdepends packagers to choose the right libcurl3-*-dev > > for them. anyway i agree with you about the wrong time to enforce this. > > > i'll re-introduce libcurl3-dev as a transition package depending on > > libcurl3-openssl-dev. anyway i don't consider this urgent and it will > > be solved with the next upload, which is not too far away. > > This kind of uncoordinated change is in fact *very* disruptive when > we're in the middle of a pile of transitions for testing; you've left all > packages that build-depend on libcurl3-dev in an unbuildable state in > unstable (38 of them, it appears), and some of these currently *need* to be > built in order to get the KDE transition through without breaking packages > in the process. Specifically, php4 and php5 are tied into the mess, and are > missing builds on various architectures which can't be done now without a > libcurl3-dev fix, or a sourceful upload of php4/5 that requires a rebuild on > all archs. > > So depending on when you think you'll upload curl again, I need to decide > whether it's quicker to do a new sourceful upload of php4 and php5, or wait > for this transition package. this is enough for me to consider such upload urgent. i'm building and uploading within minutes. thank you domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: libcurl3-dev's reverse Build-Depends
On Wed, Oct 19, 2005 at 09:24:42AM +0200, Daniel Schepler wrote: > Since libcurl3-dev was removed from unstable, suddenly a lot of packages are > now FTBFS because their Build-Depends on libcurl3-dev cannot be satisfied. > Would you consider providing a transition libcurl3-dev package for now, or > making libcurl3-openssl-dev provide libcurl3-dev? -- Unless it's your > intention to force all maintainers to choose explicitly between the openssl > and gnutls versions immediately, in which case there should be a mass bug > filing. i'd like to force rdepends packagers to choose the right libcurl3-*-dev for them. anyway i agree with you about the wrong time to enforce this. i'll re-introduce libcurl3-dev as a transition package depending on libcurl3-openssl-dev. anyway i don't consider this urgent and it will be solved with the next upload, which is not too far away. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
using symbols generated by dh_strip --dbg-package= (was Re: Bug#333253: libcurl3-dbg: segfault when using export LD_PRELOAD=/usr/lib/debug/...)
On Tue, Oct 11, 2005 at 08:17:41AM +0200, Tino Keitel wrote: > > Hi, hi Tino, > I want to debug a program which uses curl, so I did this: > > export LD_PRELOAD=/usr/lib/debug/usr/lib/libcurl.so.3.0.0 > > However, everytime I start any program now, I get a segfault. > > Is this a bug, or is it my fault? i really don't know. i'm pretty sure the file contains only debug symbols so maybe another procedure is required in order to use them. i'm CCing debian-devel mailing list to get some feedback about this issue. regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Packages that need to be rebuilt agaisnt libssl0.9.8
On Fri, Oct 07, 2005 at 06:12:33AM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 07 Oct 2005, Domenico Andreoli wrote: > > is the run for openssl 0.9.8 started anyway? i have curl and > > libapache-mod-ssl ready for the upload. > > I am going to hold out and wait at least a week. I want to know what the > release team will do re. 0.9.8. i'm seconding. what do you think about uploading stuff to experimental? > PLEASE, let's take the opportunity to enable symbol versioning. That way, > there will NOT be any need for a new transition when 0.9.9 is out. any consensus here? have the RMs any opinion about? thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Re: Packages that need to be rebuilt agaisnt libssl0.9.8
On Thu, Oct 06, 2005 at 06:29:55PM +0200, Andreas Barth wrote: > * Frank Küster ([EMAIL PROTECTED]) [051006 17:13]: > > sean finney <[EMAIL PROTECTED]> wrote: > > > > > and furthermore, there are some of us who have been quietly waiting for > > > things to settle down from the previous major transitions before doing > > > our own, at the request of the release team. > > > > I'm only following d-d-a, -private, and -devel, but that only partly, > > and *I* have not yet read anywhere that transitions are allowed again at > > all. If they are and I had known, it would have saved me quite some > > work... > > You are right - as so often. > > People are still required to speak with the release team first. But some > people prefer to make all of our life harder then necessary. > > Please again: If someone wants to make any transition, please speak > *first* with the release team. Do not just assume you can upload just > anything. We really want to finish the c++-abi-transition first. is the run for openssl 0.9.8 started anyway? i have curl and libapache-mod-ssl ready for the upload. ciao domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: curl status update
On Thu, Sep 29, 2005 at 02:31:00PM +0200, Wouter Verhelst wrote: > On Thu, Sep 29, 2005 at 02:37:35PM +0200, Marco d'Itri wrote: > > On Sep 29, Domenico Andreoli <[EMAIL PROTECTED]> wrote: > > > > > to build something with libcurl, one has to install either > > > libcurl3-openssl-dev or libcurl3-gnutls-dev. the built package will > > > depend on libcurl3 (with openssl) or libcurl3-gnutls respectively. > > Why is openssl the default? > > I think everybody agrees that in the long period everybody will want to > > use gnutls, which is supposed to have the same features but does not > > have licensing issues. > > That's actually not true, GnuTLS has the reverse licensing issues from > OpenSSL. OpenSSL cannot be linked with GPL-licensed software; GnuTLS, > OTOH, is licensed under the GPL (as opposed to the LGPL), so cannot be > linked to applications that do not want to be distributed under the > terms of the GPL (or applications that have a GPL-incompatible license, > for that matter). you are wrong, gnutls is licensed under LGPL. have a read at http://www.gnu.org/software/gnutls/. cu dom -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: curl status update
On Thu, Sep 29, 2005 at 02:37:35PM +0200, Marco d'Itri wrote: > On Sep 29, Domenico Andreoli <[EMAIL PROTECTED]> wrote: > > > to build something with libcurl, one has to install either > > libcurl3-openssl-dev or libcurl3-gnutls-dev. the built package will > > depend on libcurl3 (with openssl) or libcurl3-gnutls respectively. > Why is openssl the default? default? one has to install libcurl3-gnutls-dev or libcurl3-openssl-dev in order to build something with libcurl, there is no default choice for the developer. nobody can now hide behind a "i didn't know libcurl3-dev brings openssl in my pants". about libcurl3 being linked with openssl instead of gnutls, i'm not personally biased. i only wanted to stay on the safe side [0]. if libcurl4 comes, i will surely point it to gnutls. ciao domenico [0] http://lists.debian.org/debian-devel/2005/09/msg00079.html -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
curl status update
hi all, i've just uploaded curl 7.14.1-3 to experimental, it should put curl back in a good state. i also uploaded pycurl built using curl+gnutls. to build something with libcurl, one has to install either libcurl3-openssl-dev or libcurl3-gnutls-dev. the built package will depend on libcurl3 (with openssl) or libcurl3-gnutls respectively. both libcurl3 and libcurl3-gnutls packages may finally be installed at the same time. libcurl's rdepends packagers are now really free to choose whatever flavour of libcurl they wish. somebody will encourage the use of GnuTLS variant, others will stay with the OpenSSL one. now it is only a matter of taste, licensing or whatever else IMHO i don't even need to know. both upstream and users are now able to make their choices without me limiting them in any way. i'm sorry to have spent more than ~1.5 months before coming to a decent solution, i've been really too busy to study some of the new things i had to understand and to freshly think at what i wanted to do with them and the package. i wish to thank Elimar Riesebieter, Daniel Stenberg, Marco d'Itri, Paul TBBle Hampson, Richard Atterer, Steve Langasek, Adeodato Simó, Henrique de Moraes Holschuh, Thomas Bushnell, Otavio Salvador, Matthias Urlichs, Olaf van der Spek, Henning Makholm and all the others i sadly forgot to mention. all of them someway helped me to find a hopefully nice solution. the testing season is then opened. if no grave bugs will be discovered i'd upload -4 to unstable in a week or two. let me know. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Re: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 11:39:28AM -0400, Daniel Jacobowitz wrote: > On Sat, Sep 24, 2005 at 04:52:31PM +0200, Domenico Andreoli wrote: > > yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname > > still being libcurl.so.3. everything else is in place for a good upload. > > > > as of today, i've not found a solution different from patching the > > makefiles. i'd like a tool to modify this kind of things in the elf, > > probably elfsh is what i'm looking for. something to run after the > > build process. any idea? > > In general you can't do this unless you're replacing it with a shorter > soname. I highly recommend fixing the build system instead. the build system is automake+libtool. fixing it means telling to libtool which soname is to be used. ah.. libtool... i hate clever software.. the only way i know to achieve this is to modify the lib_LTLIBRARIES variable and releated. am i missing anything? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
error linking Boost.Serialization on hppa
hi all, i'm now pretty sure this FTBFS [0] on hppa won't go away by itself (= nobody is going to upload a new version of something in the toolchain which fixes also this problem). build error follows: /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/basic_iarchive.o(.gnu.linkonce.t._ZSt24__uninitialized_copy_auxIPjS0_ET0_T_S2_S1_11__true_type[unsigned int* std::__uninitialized_copy_aux(unsigned int*, unsigned int*, unsigned int*, __true_type)]+0x38): cannot reach 1f2f__ZSt4copyIPjS0_ET0_T_S2_S1_+0, recompile with -ffunction-sections /usr/bin/ld: bin/boost/libs/serialization/build/libboost_serialization.so/gcc/debug/shared-linkable-true/threading-multi/basic_iarchive.o(.gnu.linkonce.t._ZSt24__uninitialized_copy_auxIPjS0_ET0_T_S2_S1_11__true_type[unsigned int* std::__uninitialized_copy_aux(unsigned int*, unsigned int*, unsigned int*, __true_type)]+0x38): cannot handle R_PARISC_PCREL17F for unsigned int* std::copy(unsigned int*, unsigned int*, unsigned int*) /usr/bin/ld: final link failed: Bad value i'm unable to understand what the linker is trying to tell me. yes, i've already tried to compile using -ffunction-sections with no more luck. is this a bug of ld? gcc? boost? me? thanks for the help. cheers domenico [0] http://buildd.debian.org/fetch.php?&pkg=boost&ver=1.33.0-1&arch=hppa&stamp=1127349147&file=log&as=raw -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 04:15:53PM +0200, Elimar Riesebieter wrote: > On Sat, 17 Sep 2005 the mental interface of Domenico Andreoli told: > > It doesn't seem so: > dpkg -l | grep curl > ii curl 7.14.1-2 > ii libcurl3 7.14.1-2 > ii libcurl3-gnutls7.14.1-2 > ii libcurl3-gnutls-dev7.14.1-2 > > Building moc depending on libcurl3-gnutls-dev gives > dh_shlibdeps > debian/moc/usr/bin/mocp: /usr/lib/libcurl.so.3: version `CURL_GNUTLS_3' not > found (required by debian/moc/usr/bin/mocp) > > Why /usr/lib/libcurl.so.3 and not /usr/lib/libcurl-gnutls.so.3? > > ldd ./mocp | egrep "(ssl|gnutls)" > ./mocp: /usr/lib/libcurl.so.3: version `CURL_GNUTLS_3' not found (required by > ./mocp) > libgnutls.so.11 => /usr/lib/libgnutls.so.11 (0x0fc3b000) > libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x0f7df000) yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname still being libcurl.so.3. everything else is in place for a good upload. as of today, i've not found a solution different from patching the makefiles. i'd like a tool to modify this kind of things in the elf, probably elfsh is what i'm looking for. something to run after the build process. any idea? i'm also sorry for being not responsive at all, my real life should return to me some of the good old free time in a week or two. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#318590: curl situation is intolerable
On Mon, Sep 12, 2005 at 03:03:02AM -0700, Steve Langasek wrote: > On Mon, Sep 12, 2005 at 11:34:22AM +0200, Domenico Andreoli wrote: > > will libcurl3 with versioned symbols break existing packages linked > > to it? > > It will not. good > It would be best to coordinate with upstream to get symbol versioning > added there as well, so that binaries built against the symbol-versioned > Debian lib can also be run on other systems. i already contacted him cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: curl situation is intolerable
On Sun, Sep 11, 2005 at 09:46:26PM -0700, Thomas Bushnell BSG wrote: > Paul TBBle Hampson <[EMAIL PROTECTED]> writes: > > > Mind you, the license/OpenSSLCallback conflict neccessarily > > segregates the packages into two camps, those which are GPL, and > > those which need the callback only supplied by the OpenSSL-linked > > libcurl. > > You misunderstand my complaint. > > I do not care that a given package cannot link to SSL and also be > GPLd. That's a hassle, but it's endurable. > > What I complain is that, once the packages have been so segregated, it > is now *impossible* to even install both kinds on the same Debian > system at the same time. *That* is intolerable. > > I don't care about the callback. The package maintainers have the job > of deciding whether the packages implement the same ABI or not. > DECIDE. > > If the answer is "yes", then they should both be drop-in replacements, > and Provide the same virtual package. > > If the answer is "no", then they should install different files in the > Debian namespace and should not Conflict with each other. > > DECIDE, and then do whichever. But the current "solution" is utterly > unacceptible. Thomas, i'm aware of the poor (non-)solution currently realized. yesterday i was rolling a new upload with a modified name for libcurl3-gnutls to allow both the packages to be installed at the same time when i finally understood why i probably need versioned symbols. then i looked for some kind soul (Matthias Urlichs) who introduced me to the world of versioned symbols. so my next favourite solution is: curl openssl libcurl3 openssl, versioned symbols libcurl3-dev openssl libcurl3-gnutlsgnutls, versioned symbols libcurl3-gnutls-dev gnutls libcurl3-dbg openssl will libcurl3 with versioned symbols break existing packages linked to it? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#318590: curl situation is intolerable
On Sun, Sep 11, 2005 at 10:54:17AM -0300, Henrique de Moraes Holschuh wrote: > On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote: > > It is *absolutely intolerable* to declare such conflicts for shared > > libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT > > HAVE DIFFERENT NAMES. > > The package has to build libraries with differently versioned symbols as > well, to avoid total app meltdown if both libraries are loaded into the same > address space. hmm.. i didn't realized this. how does it work? -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#318590: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote: > On Fri, Sep 02, 2005 at 12:24:18PM +0200, Domenico Andreoli wrote: > > > > - libcurl3 (GnuTLS, soname: libcurl.so.3) > > > > So the libcurl3 in sarge and etch will have ABI incompatibilities? > > > at the release time of etch this problem will regard only > > external software. this kind of installations will be able to use > > libcurl3-openssl-dev package or switch to GnuTLS. > > > is this reasonable enough? > > No, definitely not. You cannot change the ABI of an existing library > package, especially not one that's been in a stable release; you need > to rename it instead. so we need both libcurl3-openssl and libcurl3-gnutls until libcurl4? i am not seeing this as a problem. dom -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#318590: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 11:56:13AM +0200, Adeodato Simó wrote: > * Domenico Andreoli [Fri, 02 Sep 2005 11:16:28 +0200]: > > > - libcurl3-dev (OpenSSL, depends: libssl-dev) > > - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) > > Obvious typo/whatever here, right? On Fri, Sep 02, 2005 at 02:58:05AM -0700, Steve Langasek wrote: > Your -dev package names seem to be crossed, relative to the > corresponding lib packages. I think you really wanted to say > > - libcurl3-dev (GnuTLS, depends: libgnutls-dev) > - libcurl3-openssl-dev (OpenSSL, depends: libssl-dev) > > ? yes > > - libcurl3 (GnuTLS, soname: libcurl.so.3) > > So the libcurl3 in sarge and etch will have ABI incompatibilities? at the release time of etch this problem will regard only external software. this kind of installations will be able to use libcurl3-openssl-dev package or switch to GnuTLS. is this reasonable enough? thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 02:58:05AM -0700, Steve Langasek wrote: > On Fri, Sep 02, 2005 at 11:16:28AM +0200, Domenico Andreoli wrote: > > > ok, we are hooked into the libflac6 transition, let's start the curl one. > > > my wish is to upload curl 7.14.1 with the following package layout: > > > - curl (OpenSSL, linked to libcurl-openssl.so.3) > > - libcurl3 (GnuTLS, soname: libcurl.so.3) > > - libcurl3-openssl (OpenSSL, soname: libcurl-openssl.so.3) > > - libcurl3-gssapi (OpenSSL, MIT Kerberos 5) > > - libcurl3-dev (OpenSSL, depends: libssl-dev) > > - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) > > - libcurl3-dbg > > > this way libcurl3 and libcurl3-openssl can be contemporarily installed. > > > curl command line depends on package libcurl3-openssl. BTW, is > > libcurl3-openssl legal or it should be libcurl-openssl3? > > > any more comments? > > Why does libcurl3-gssapi need a separate package from libcurl3-openssl? probably none. in case it is acceptable to enable GSSAPI everywhere, i could also enable it in the libcurl3 (with GnuTLS) and remove libcurl3-gssapi completely. > Your -dev package names seem to be crossed, relative to the > corresponding lib packages. I think you really wanted to say > > - libcurl3-dev (GnuTLS, depends: libgnutls-dev) > - libcurl3-openssl-dev (OpenSSL, depends: libssl-dev) > > ? yes, of course :) > And yes, lintian will complain to you if you name your library package > libcurl3-openssl instead of libcurl-openssl3. :) lintian would be shut up with an ovverride... no remorse. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#325643: libcurl and moc
On Thu, Sep 01, 2005 at 09:40:17PM +0200, Elimar Riesebieter wrote: > > On Tue, 30 Aug 2005 the mental interface of Daniel Stenberg told: > > > > The problem you have with libcurl and OpenSSL/GnuTLS is not strictly an > > "upstream problem". > > > > In the curl project there are some ideas floating around that are being > > discussed on how this could be fixed for Debian (and other distros) but > > that is > > only because they don't do it themselves, it is not because it is an actual > > problem in the curl camp. It is more of an indirect annoyance. > > > > Also, discussions are only talk. There is no fix or solution in the work > > for > > the nearest period of time. Everyone's invited to come help sort it out. > > > > In my view, there's only one available work-around for the short to mid > > term, > > and that is to use a separate .so file for libcurl built with GnuTLS. > > My resume on Daniels point of view is to get a different .so name > for gnutls in the very short term and kick off ssl in Debian apps > midterm! Note, this will _not be done upstream_! This is not as hard > as Marco's demand, but we have to do it in that way. There are some > curl based packages like oggvorbistools, moc etc which are at the > moment uninstallable and herewith I invite Domenico to provide a > package where gnutls and ssl can exist beside in one installation. > For me, as a not much experienced voluntary I'll spend some spare > time to understand the technique on how to do that and hopefully can > assist Domenico to create a package. ok, we are hooked into the libflac6 transition, let's start the curl one. my wish is to upload curl 7.14.1 with the following package layout: - curl (OpenSSL, linked to libcurl-openssl.so.3) - libcurl3 (GnuTLS, soname: libcurl.so.3) - libcurl3-openssl (OpenSSL, soname: libcurl-openssl.so.3) - libcurl3-gssapi (OpenSSL, MIT Kerberos 5) - libcurl3-dev (OpenSSL, depends: libssl-dev) - libcurl3-openssl-dev (GnuTLS, depends: libgnutls-dev) - libcurl3-dbg this way libcurl3 and libcurl3-openssl can be contemporarily installed. curl command line depends on package libcurl3-openssl. BTW, is libcurl3-openssl legal or it should be libcurl-openssl3? any more comments? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Bug#318590: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem
On Wed, Aug 24, 2005 at 04:23:19PM +0200, Marco d'Itri wrote: > On Aug 24, Domenico Andreoli <[EMAIL PROTECTED]> wrote: > > > in the meanwhile new packages can be built using the gnutls variant of > > libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot > > be installed at the same time. > What is the point then? They *will* be needed at the same time. > If they cannot be installed on the same system then looks like you are > wasting your time. the conflict is temporary. as soon as curl is fixed with this regard the conflict will be removed and the packages depending on libcurl3-gnutls will be bugged to be rebuilt. > That "solution", BTW is a disgusting hack. Daniel will be surely happy to see better patches. regarding me, i prefer disgusting over inexistent. if only Daniel liked the idea of using plugins in curl... eh, Daniel? > Again, there should be no reasons to need to use a openssl instead of > gnutls. If some program really needs it, then it should be linked to a > *special* libcurl-with-openssl library until it can be fixed. > But the default should be to use gnutls. gnutls is not mature, it has been just added. people willing to test it and signal bugs are welcome. -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem
On Fri, Aug 19, 2005 at 12:07:09PM +1000, Paul TBBle Hampson wrote: > On Thu, Aug 18, 2005 at 11:00:41AM +0200, Domenico Andreoli wrote: > > with curl 7.14.0-5 currently in incoming, i added two new packages > > libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls > > conflict each other since both install libcurl.so.3.0.0 in /usr/lib/. > > If the problem is that using gnutls or openssl changes the ABI for libcurl, > then they should have different sonames. (I'd expect the newer one, gnuTLS, > would get its own soname, so that existing packages work, and packages can > optionally build against the gnuTLS version if they so wish. Once everything > builds happily against the gnuTLS version, the next upstream soname bump can > use the gnuTLS library, and we're compatible with other distributions again.) problem is right the change of ABI. Daniel Stenberg (the upstream developer) is available to implement a solution based on the proposal of Richard Atterer [0]. in the meanwhile new packages can be built using the gnutls variant of libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot be installed at the same time. cheers domenico [0] http://curl.haxx.se/mail/lib-2005-08/0118.html -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem
hi all, with curl 7.14.0-5 currently in incoming, i added two new packages libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls conflict each other since both install libcurl.so.3.0.0 in /usr/lib/. doesn't this still scare you? then try to figure what will happen when you install the first package depending on libcurl3-gnutls on a system with openoffice (or php4-curl, vorbis-tools, ...) installed. i realized this only while i was writing the packages conflicts but the more i think at it the more i feel nervous. libcurl3 has ~80 rdepends (when they became so many?!?) and i'd like to not be f*cked too hard trying to figure the best solution. should i really let 7.14.0-5 be installed? should i change the soname of the gnutls variant? i suppose other packages already had this problem, any wise advice? many thanks. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
curl reverts to openssl (but the story does not ends here)
reopen 318590 thanks hi dear developers, it looks like i completely underestimated the transition of curl to gnutls [0]. so i have just made a new upload which settles the things back to openssl. i don't want to start any transition right now, also because upstream developer made me note that the gnutls support is still young. these are bad news for those gpl packages waiting for libcurl with no openssl. they will have to wait a little more. i'm sorry for this. in talking about the solution IMHO things get hotter. probably the next simpler solution is to add libcurl3-gnutls and, if required, libcurl3-gnutls-dev packages. but somebody could prefer a -nossl version (like that still in woody, the one i should have never removed). BTW what about gssapi support? kerberos or heimdal? hmmm... there is smell of combinatorial explosion. debian is about choice, not explosions, isn't it? how much it is for choice and how much is for explosions? i continue to think that having only a curl+gnutls package is the long term solution but i'll be glad to hear also your opinion and suggestions. [1] thank you domenico [0] probably because i never wanted to start such transition. my hope was to (ingenuously) hide the change within the curl build process. [1] yes, recently a thread talked right about curl and openssl vs. gnutls, but evidently i didn't see what i call a general consensus. -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
MIT krb5 vs. Heimdal for curl's GSSAPI support (Re: Who needs libcurl3?)
[ CCing curl-library ml ] On Mon, Jul 25, 2005 at 12:12:03PM -0400, Aaron M. Ucko wrote: > Domenico Andreoli <[EMAIL PROTECTED]> writes: > > > unfortunately heimdal bug #316980 makes curl FTBS :( > > :-/ Can you use MIT krb5 instead? sure :) i'm not a kerberos guru, i never used it and probably i will never be interested in it. i added this package only after a debian user asked for GSSAPI support in curl (FYI bug #241553). anybody knows if curl will modify its behaviour switching to MIT krb5? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Fri, Jul 22, 2005 at 07:15:18PM +0200, Elimar Riesebieter wrote: > On Mon, 18 Jul 2005 the mental interface of > Domenico Andreoli told: > > [...] > > i doubt seriously a new package like libcurl3-gnutls is appropriate, > > but let me know your opinion. > > > > is this stuff urgent? > Yes! unfortunately heimdal bug #316980 makes curl FTBS :( regards domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)
On Sun, Jul 17, 2005 at 03:19:54PM -0400, sean finney wrote: > On Sun, Jul 17, 2005 at 09:04:57PM +0200, Elimar Riesebieter wrote: > > Why not building curl --without-sssl and --with-gnutls=/usr? Maybe a > > NMU? > > this is definitely NOT a reason to NMU libcurl. remember that it is > your package that is "broken". of course you could still file a > wishlist bug against libcurl asking to compile against gnutls > instead, but it's up to the maintainer in question to decide. oh, many thanks for the stop :) i saw the bug report, i'm sorry to not have commented the request which i find absolutely reasonable. i'll try to figure out if curl may suffer from limitations due to the use of gnutls in place of openssl. i doubt seriously a new package like libcurl3-gnutls is appropriate, but let me know your opinion. is this stuff urgent? cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
bug count is going to hit #300000! (was Re: Bug#299919: samba-common: ...)
On Thu, Mar 17, 2005 at 10:47:15PM +1100, Andrew Bartlett wrote: > On Thu, 2005-03-17 at 12:11 +0100, Domenico Andreoli wrote: > > Package: samba-common > > Version: 3.0.10-1 > > Severity: minor > > > > hi, > > > > i'm seeing there is file /etc/samba/gdbcommands. it looks like it > > is installed by samba-common by error. could please remove it from > > the package? > > This file is used by the panic action specified by the smb.conf. This > is deliberate. ah.. ok. sorry to have wasted a bug :) hey, we are near bug #30! (299925 currently. who'll ride the next?) happy hacking to all :) cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: list what's in the NEW queue?
On Wed, Feb 02, 2005 at 06:28:58PM +0100, Jeroen van Wolffelaar wrote: > > Debian New queue summary, > http://developer.skolelinux.no/~pere/debian-NEW.html i never made this question to myself but i'm finding the answer very interesting. just a curiosity. why there are packages like kernel-patch-2.4-blooper, kernel-linux-experimental-defaults, rte, kernel-linux-experimental-2.4 which are many months or years old? cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: dselect and its help messages
On Thu, Jan 13, 2005 at 02:00:23PM +1100, Hamish Moffatt wrote: > On Wed, Jan 12, 2005 at 03:20:19PM +, Colin Watson wrote: > > The change *to* Enter was the thing that broke dselect for those of us > > who have been using it since woody and earlier. Switching back to the > > old behaviour unbroke it. As the changelog message states, encouraging > > people to press Enter in dselect is dangerous. > > > > Use 'dselect --expert' if you don't want to see the help messages at > > all. > > How about a way to suppress the help screen permanently, such as an > environment option or dotfile? > > I can't get rid of it quickly enough. What other program shows you its > help screen every time you run it? And space to dismiss the help screen > is not very intuitive. since it is a help message, it could well tell the user how to get rid of it permanently, couldn't it? something like: If you want to get rid of this help message use the --expert command-line switch or set the expert option in file /etc/dpkg/dselect.cfg. wouldn't it be appropriate in both the opening and conflict resolution help screens? my last 2 cents to the topic... cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: dselect and its help messages
On Thu, Jan 13, 2005 at 11:00:26AM +, Colin Watson wrote: > On Thu, Jan 13, 2005 at 11:54:56AM +0100, Domenico Andreoli wrote: > > > > if the fact of hitting Enter to dismiss the help message confuses the > > user at the point he instead commits changes, it looks like we need > > another way to confirm rm -rf because people might be confused and wipe > > the disk. > > No, it's not that. The point is that it's very easy - trivially easy, > and often done - to hit Enter twice when you only meant to hit it once, > and if you do that at dselect's help screen then you commit all its > suggested changes to new packages without getting a chance to look at > them. That's just terrible UI design. > > People often complain about dselect's user interface, but let's not make > gratuitously bad UI decisions! Enter was explicitly avoided at the help > screen when dselect was written for this exact reason, but this decision > was forgotten when making the change. now that i know about the expert mode, i agree with you. i was complaining about a misuse of the interface. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: dselect and its help messages
On Wed, Jan 12, 2005 at 02:52:47PM +, Scott James Remnant wrote: > On Wed, 2005-01-12 at 11:19 +0100, Domenico Andreoli wrote: > > > > IMHO people confused by dselect should switch to another dpkg/apt > > frontend and not break it. > > > Exactly, I agree *entirely*. > > dselect has always used space to dismiss help messages and the current > stable (woody) version of dselect still uses space to dismiss help > messages. yes, i'm aware of this. indeed i suppose you got many more sad users because of the new behaviour than because of the original one. but this is not the real problem, since it could be solved allowing both Enter and Space to dismiss help messages. > People were confused by this, so dselect was broken in unstable to allow > Enter to be used. Rather than breaking dselect, those people should > switch to another dpkg/apt frontend. are you saying i should use another frontend? tell me the truth and be explicit, please :) > As noted in the changelog, Enter (and 'Q') in dselect are dangerous > keys, they commit changes. Encouraging uses to hit Enter to dismiss > screens they don't know about is therefore encouraging users to commit > changes without considering them. if the fact of hitting Enter to dismiss the help message confuses the user at the point he instead commits changes, it looks like we need another way to confirm rm -rf because people might be confused and wipe the disk. anyway, let me stop here. i don't want to start a flamewar. i wanted only to cry publicly about the removal of something i found useful, but apparently i'm alone. so it is really better the old behaviour has been restored and peace with you all. thank you for the --expert tip, i should have read it in the manpage long time ago. cheers domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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]
dselect and its help messages
> dpkg (1.10.26) unstable; urgency=low > > * ... > > * Revert to current 'stable' behaviour of Space/Enter/'Q' in the dselect > help screen, Space leaves the help screen and Enter and 'Q' do nothing. > It's dangerous to encourage users to press Enter or 'Q' since they > commit changes in the package selection screen. > > * ... > > -- Scott James Remnant <[EMAIL PROTECTED]> Tue, 11 Jan 2005 16:26:51 + oh no, these are bad news :( i found it very fast using Enter to exit the help message. i'm not talking about the first one shown on entering package selection but the (usually "many") ones shown before dependency conflict resolution. it was everything in the right hand... really fast. and i've never been confused by this behaviour. IMHO people confused by dselect should switch to another dpkg/apt frontend and not break it. i hate hitting space to dismiss the help messages, i realized this when Enter was introduced to dismiss them. i really liked/loved this feature... sob :(( domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~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: debian kernel 2.6.9 with selinux enabled!
On Wed, Dec 01, 2004 at 07:45:58PM +, Luke Kenneth Casson Leighton wrote: > manoj, thank you. thank you thank you *smooch*. uh? could you please elaborate a little? ;) cheers dom -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
perl 5.8.2-2 & mips buildd
hi, i see that perl 5.8.2-2 is marked "Not-For-Us" on mips buildd. why it is in this state? it blocks the build of a lot of software. cheers dom -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Latest version of fvwm packaged
On Tue, Nov 11, 2003 at 02:39:15AM -0600, Manoj Srivastava wrote: > The development branch of fvwm is nearing a stable release, > and has had a huge number of new features. The maintainer has been > very reluctant to package this branch, even in a people.debian.org > repository, so I decided to package FVWM 2.5.8 for myself; and I have > decided to share this with others as well. The packages are > lintian clean, and can be found at: > > deb http://people.debian.org/~srivasta/ packages/ > deb-src http://people.debian.org/~srivasta/ packages/source/ > cool... hehe :)) -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: 2.5 IPsec kernel patch: orphaning the grsecurity patch
On Thu, Oct 16, 2003 at 02:12:55PM -0400, Matt Zimmerman wrote: > On Thu, Oct 16, 2003 at 07:05:56PM +0200, martin f krafft wrote: > > > also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2003.10.11.0554 +0200]: > > > People care more about some things than others. Given a choice between > > > IPsec in Debian kernels by default and being able to apply grsecurity to > > > Debian kernel source, I'd take IPsec anyday. > > > > Well, I would do it the other way. And if there was a patch for > > IPsec just like there is for grsecurity, we could both have our > > ways. > > We still can; you just have to do a little work, either to port the patch > (apparently too difficult), or to revert the portions of the IPsec patch > which cause problems for grsecurity. > who should do this little work? the user or the grsecurity patch maintainer? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Looking for a co-maintainer for adduser
On Thu, Oct 02, 2003 at 10:02:38AM +0200, Roland Bauerschmidt wrote: > The number of bugs on the adduser package has constantly increased for > the last few months, though none of them is release critical. Since I > was busy with other stuff (mostly OpenLDAP and related stuff) I didn't > keep up with all the feature requests and non-critical bugs. This is > also partly due to the fact that I don't like the way adduser is > currently written (and also perl) a lot, and was planning to do a > complete overhaul (http://www.hbg-bremen.de/~roland/code/adduser.xhtml). > i could be interested > Matthew Palmer has done some nice work in abstracting the passwd storage > backend, and adding methods for LDAP storage. The latter, though, still > needs some more work to be useful in different directory structures. > i have developed a system in python which abstracts from the backend too. moreover it is easily expandable with python plugins. it is also easy to develop new applications/utilities using it as a python module. it is pretty stable, i already use it in production system. http://www.nongnu.org/prua/ > I am thus seeking for one or two co-maintainers, and appreciate it a lot > if Matthew would chose to be one of them. The package is managed in a > Subversion repository on Alioth. The main package is in trunk, Matthew's > LDAP extended version in brances/adduser-ldap (which should eventually > be merged into trunk); all in the svn+ssh://svn.debian.org/svn/adduser > repository. It'd be particularly useful, if you have NIS experience (and > maybe even a running setup), but not required. There is an adduser-devel > also on Alioth. > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: 2.5/2.6 IPsec stack should live in a kernel-patch!
On Wed, Oct 01, 2003 at 05:38:51PM -0500, Steve Langasek wrote: > [ObPrivate: this doesn't belong on private. Quote me freely.] > > On Wed, Oct 01, 2003 at 11:56:14PM +0200, martin f krafft wrote: > > > Thus I propose that Herbert should remove the IPsec patch and make > > it a separate kernel-patch. If anyone has other objections than "I > > won't do it because it's my choice, I don't feel like it, and there > > is nothing you can do about it", then please speak up. On the other > > hand, if you agree with me, let your voice be heard! > i'm interested only in the debian kernel without 2.5/2.6 IPsec. in my mind this should be vanilla kernel + debian fixes. ... > If you want this inter-developer dispute to be taken *seriously*, that > is most likely a matter for the technical committee (debian-ctte). > i vote for this bye -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote: > George Danchev <[EMAIL PROTECTED]> wrote: > > > > it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is > > useless, > > leave to users to patch if they want) then all other > > kernel-patch- > > packages will be fine. > > It is unacceptable for us to distribute kernels with known (security) bugs. sorry for the profane question, is IPsec related to any security issue in 2.4.2x kernels? i don't care about IPsec, i don't either know what it really is and i'm having problems with it. is there a way to throw away it without loose other bugs fixes? thanks dom -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: python 2.2 -> python 2.3 transition
i agree, we have a great support for Python. thanks to those who make it possible. cavok On Thu, Aug 07, 2003 at 11:47:48AM +1000, Donovan Baarda wrote: ... > > Personally I was going to post "nice job everyone... the Python Policy > looks like it is working". There are still a few niggly things, but if > Debian can go to Python 2.3 within days of it being released without > breaking anything else, I'd say thats pretty damn impressive. > ... -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
howto use chroot on merulo?
hi, i need to build curl on ia64 to see why it fails the test phase. i'm thinking to use merulo, the only machine which provides chroots (i suppose) to compile stuff for sarge, but i never used chroots on project machines. any hint? i gave a glance to the developer reference but i didn't find anything useful. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpoFcZpCFzD6.pgp Description: PGP signature
Re: python 2.2 -> python 2.3 transition
hmmm.. just curious... why? On Wed, Aug 06, 2003 at 11:18:53AM +0200, Josip Rodin wrote: > On Tue, Aug 05, 2003 at 10:31:53PM +0200, Matthias Klose wrote: > > Last weekend, python 2.3 was released. > > With the next python2.3 upload, python2.3 becomes the default python > > version. > > Am I the only one who has a disgusting reminiscence of netscape*.* packages > every time python* is mentioned? :P > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: libstdc++... Help please
http://snapshot.debian.net/archive/2003/04/28/debian/pool/main/g/gcc-3.3/libstdc++5_3.3-0pre5_i386.deb On Tue, Apr 29, 2003 at 12:02:38PM +, Nick Burkett wrote: > > Hi, > I've just upgraded my sid system (i386) without > realising that libstdc++-pre6 is completely broken... > I've got an essay due in 24 hours which (was) being > written in lyx (which now doesn't work). Does anyone know > where I can get a pre5 version of libstdc++ from (my local > cache doesn't have it). Please CC me as I'm not on the mailing > list. > > Thanks, > Nick > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Tue, Apr 22, 2003 at 11:45:08PM +0200, Bj?rn Stenberg wrote: > Colin Watson wrote: > > The reason why a library's shlibs get changed > > is that binaries built against one version of the library can't be > > guaranteed to run correctly against older versions. > > Because the interface changed or because the previous version was buggy? > > I have always assumed the first reason, but it seems many maintainers are > using the second. > first reason, interface changes. libcurl provides a function (curl_easy_setopt) which is used to set options for the run. if new options are added i have to change shlibs, i cannot know whether a program linking the new libcurl uses any new option. hence, i cannot allow its installation with an older libcurl. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
anti-spam trick for debian ml (was Re: News about the Package Tracking System)
On Sun, Apr 20, 2003 at 02:49:26PM +0200, Raphael Hertzog wrote: > Hi folks, > hi Raphael, > I just made an important change to PTS. Since the PTS email adresses > have been available on the web, they start collecting a significant > quantity of spam. As a first measure to avoid them I decided that any > email sent directly to the PTS should be auto-approved. Auto-approval is > easy, you just have to add an "X-PTS-Approved" header with a non-empty > value. If you don't do that, you get a bounce (and the bounce explains > you how to auto-approve your message). > why not use this trick also for posts to debian mailing lists? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Bug#189626: ITP: python-crack -- Python bindings for cracklib
Package: wnpp Version: N/A; reported 2003-04-19 Severity: wishlist * Package name: python-crack Version : 0.2 Upstream Author : Domenico Andreoli <[EMAIL PROTECTED]> * URL : http://www.nongnu.org/python-crack * License : GPL Description : Python bindings for cracklib -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux filibusta.crema.unimi.it 2.4.18-cavok #1 Tue Aug 6 10:57:32 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
On Mon, Apr 14, 2003 at 05:17:33PM +0200, Matthias Urlichs wrote: > Duh. You're right. I admit to not being able to think of any other good > (i.e. not-a-bug) reason why this dependency should be there, then. Since > one of my packages has the same problem, I'll go and check why > dpkg-shlibdeps (what else??) thinks so. > package dependencies are ok, so dpkg-shlibdeps is not wrong. at least on i386. -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
$ ldd `which curl` libcurl.so.2 => /usr/lib/libcurl.so.2 (0x27ae1000) libssl.so.0.9.7 => /usr/lib/i686/cmov/libssl.so.0.9.7 (0x27b06000) libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x27b35000) libdl.so.2 => /lib/libdl.so.2 (0x27c25000) libz.so.1 => /lib/libz.so.1 (0x27c28000) libc.so.6 => /lib/libc.so.6 (0x27c35000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x27ac3000) $ hmmm... doesn't look as if it depend on any ligcc-3.2 On Mon, Apr 14, 2003 at 04:52:00PM +0200, Matthias Urlichs wrote: > Hi, > > On Mon, 14 Apr 2003 13:56:48 +, Domenico Andreoli wrote: > > i don't really know where that gcc-3.2 is coming from. as you can see curl > > doesn't depend on it explicitly. > > > If it is built with gcc-3.2 and it needs a symbol from libgcc-3.2, then > the resulting package will depend on gcc-3.2. > > I can't think of an easy fix. The packages in unstable are supposed to move to > testing as-is, and IMHO automatically trying to re-build them in testing > when that doesn't work because of auto-generated dependencies (how do you > find those?) sort of defeats the whole idea. > > Maybe it's time to force gcc-3.2 into testing..? > > > -- > Matthias > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
curl, testing and gcc-3.2 (?) (was Re: Debian curl package depends on gcc-3.2?)
hi, i don't really know where that gcc-3.2 is coming from. as you can see curl doesn't depend on it explicitly. anyway debian has migrated to gcc 3.2 as default compiler and i build curl with gcc 3.2 since a couple of releases ago. maybe it is required someway. i'm CC debian-devel@, maybe some kind soul might help here cheers cavok $ dpkg -s curl libcurl2 Package: curl Status: install ok installed Priority: optional Section: web Installed-Size: 284 Maintainer: Domenico Andreoli <[EMAIL PROTECTED]> Version: 7.10.4-1 Replaces: curl-ssl Provides: curl-ssl Depends: libc6 (>= 2.3.1-1), libcurl2 (>= 7.10.4-1), libssl0.9.7, zlib1g (>= 1:1.1.4) Description: Get a file from an HTTP, HTTPS, FTP or GOPHER server curl is a client to get 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. . More information can be found at the curl web site http://curl.haxx.se . Package: libcurl2 Status: install ok installed Priority: optional Section: libs Installed-Size: 512 Maintainer: Domenico Andreoli <[EMAIL PROTECTED]> Source: curl Version: 7.10.4-1 Replaces: libcurl2-ssl Provides: libcurl2-ssl Depends: libc6 (>= 2.3.1-1), libssl0.9.7, zlib1g (>= 1:1.1.4) Suggests: ca-certificates Description: Multi-protocol file transfer library, now with SSL support! libcurl is designed to be a solid, usable, reliable and portable multi-protocol file transfer library. . This is the shared version of libcurl. . More information can be found at the curl web site http://curl.haxx.se . On Mon, Apr 14, 2003 at 01:17:44PM +0200, Bj?rn Stenberg wrote: > Hi. > > I'm looking at http://packages.qa.debian.org/c/curl.html and noticed it says > curl depends on gcc-3.2. How come? I spoke to Daniel and he says he never > even uses gcc 3.2, so it's obviously not an upstream dependency. > > The reason I'm asking is that this dependency stops curl from entering > testing. Testing now contains a curl version that is over a year old. > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
can aspell drop hppa for now? (was Re: gcc-3.0 problems)
dear debian mates, i'm in the same situation of tomas, i'm sure that aspell won't compile on hppa in time for woody release. it has some kind of problem with gcc 3.0 i cannot manage and i'm not receiving any help (see bug #139515). i think that leaving current aspell out of woody would be a mistake, i'd prefer to drop hppa for the moment. i'm going to upload the new packages before next weekend. cheers cavok On Mon, Apr 15, 2002 at 11:43:19PM +0200, Tomas Pospisek's Mailing Lists wrote: > My knowledge of gcc-2.95 vs gcc-3.0 intricacies and C++ specialities is > far too small to figure out what's going on here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140032 > > and I estimate that I won't have the time to improve my knowledge > sufficiently either untill woody deadline so I plan to drop support for > all platforms that _require_ gcc-3.0. How would I achieve that: > > * by explicitly adding "Conflicts: gcc-3.0" to the control file? > * by explicitly naming all supported plattforms? > * by excluding some architectures (this doesn't seem to be possible) > > The upstream who's much more knowledgeable won't be available during the > next two weeks either. So if there's any g++-3.0 guru listening, then I'd > be glad for some hints. > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpowUoUvg8hq.pgp Description: PGP signature
Re: Requesting for comments: automatically and mechanically obtaining shared library package names
hi Junichi,
i think this could well be an option for debmake or dh_make in order
to help build initial debian/control file
On Sat, Apr 13, 2002 at 02:32:50PM +0900, Junichi Uekawa wrote:
>
> USAGE:
>
> $ libinfodump.sh /usr/lib/libdmachinemon.so.1.0.0
> Package: libdmachinemon1
> Section: libs
> Depends: ${shlibs:Depends}
>
> Package: libdmachinemon1-dev
> Section: devel
> Depends: libpthread0-dev,libc6-dev
>
>
> For discussion on best-practice in library packaging, see
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
>
-[ 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: Release-critical Bugreport for April 12, 2002
On Fri, Apr 12, 2002 at 06:00:03AM -0500, BugScan reporter wrote: > Maintainer: Domenico Andreoli <[EMAIL PROTECTED]> > 139515 [ H] aspell: FTBFS: SEGV in aspell during build (hppa/unstable) > it seems a problem due to gcc 3.0 (the default on hppa). also on upstream mailing list somebody reported problem looking like this one using a gcc 3.0 on i386 IIRC. anyway i'm not able to proceed with further tests. i'm not aware of anysolution nor workaround. anybody willing to give a hand is very welcome. cheers cavok -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpyiuk2lexec.pgp Description: PGP signature
please test gshield 2.7.1 package for debian
hi all, i packaged gshield 2.7.1 for debian. everything is available at http://filibusta.crema.unimi.it/~cavok/gshield/ . please check it! thanks cavok -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 pgpn0d9AiaC12.pgp Description: PGP signature
Re: Bug#140183: aspell does install or depend on any languages
On Fri, Mar 29, 2002 at 05:10:55PM -0500, Anthony DeRobertis wrote: ... > > I argue that checking spelling is a 'significant amount of > functionality' for a spell checker. I believe we agree that dictionaries > are needed for that function ;-) > also word list generation is a "significant amount o functionality" to my eyes and this doesn't need any dictionary installed. this is a particular, rare but valid situation for the user, it is used for building aspell dictionary packages. > I'd argue that aspell depending on the dictionaries is better than the > dictionaries on the library. The dictionaries could then Recommend: the > spell checker. > open your eyes, aspell (well, its library) somewhat depends on its damned dictionaries Recommends is only a lighter Depends and it would be very very fine if people wouldn't ignore it. do not blame my relationships only because apt-get does not honour them, i'm using policy and it is much older than apt-get, ok? you raised a good problem but you are trying to solve it in the wrong place, look: [EMAIL PROTECTED] 1 ~<% grep ^Recommends: /var/lib/dpkg/available|wc -l 1077 all thess packages use Recommends and all would break thanks to apt-get. solving the problem your way would may be ok for aspell but still would leave 1076 broken packages. installing any of these 1076 packages with apt-get would happily drop important pieces of software, this is the real bug. now, this priority is too high and i don't see too many people agreeing with you... ciao cavok -[ 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: Bug#66135: libtool_1.3.5-1(unstable): wrapping of binaries fails with -D__LIBTOOL_IS_A_FOOL__
On Fri, Sep 21, 2001 at 07:12:24PM +1000, Brian May wrote: > >>>>> "Domenico" == Domenico Andreoli <[EMAIL PROTECTED]> writes: > > Domenico> On Thu, Sep 20, 2001 at 10:36:12AM -0700, Ossama Othman > Domenico> wrote: > >> Hi, > >> > >> On Thu, Sep 20, 2001 at 04:09:38PM +0200, Domenico Andreoli wrote: > >> > ehm... this bug seems to be preventing lots of packages to > >> make in > testing, shouldn't it get some more attention? > >> > >> I was under the impression this bug was fixed in libtool 1.4.x. > >> Is that not the case? > >> > Domenico> i do not know wether it is fixed or not, this bug is > Domenico> still outstanding and its severity is set to "Serious > Domenico> policy violation", this prevents it making into testing > Domenico> (see update excuses). > > This "bug" is only because of debian/rules which continue to use an > obsolete (and no longer required) hack in order to remove unwanted > -rpaths. > how to find these evil packages? > Just remove the hack, it is no longer required. It no longer serves > any useful function either. > > For more details read the bug report. > -- > Brian May <[EMAIL PROTECTED]> > > > -- > 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: please test this lintian release
On Thu, Sep 20, 2001 at 02:17:47PM -0700, Sean 'Shaleh' Perry wrote: > http://people.debian.org/~shaleh/lintian. > > there is some problem with debian/Debian spell checking, it reports "spelling-error-in-copyright debian Debian" even if it is (IMHO) ok. lintian 1.20.14.1 says nothing about the same package. this is my copyright file -cut here-- This package was debianized by Domenico Andreoli <[EMAIL PROTECTED]> on Thu, 17 May 2001 12:46:08 +0200. It was downloaded from ftp://ftp.gnupdate.org/pub/gnupdate/ Upstream Author: Christian Hammond <[EMAIL PROTECTED]> Copyright: (C) 1999-2001 The GNUpdate Project. This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. On Debian GNU/Linux systems, the complete text of the GNU Lesser General Public License can be found in `/usr/share/common-licenses'. -cut here-- > -- > 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: Bug#66135: libtool_1.3.5-1(unstable): wrapping of binaries fails with -D__LIBTOOL_IS_A_FOOL__
On Thu, Sep 20, 2001 at 10:36:12AM -0700, Ossama Othman wrote: > Hi, > > On Thu, Sep 20, 2001 at 04:09:38PM +0200, Domenico Andreoli wrote: > > ehm... this bug seems to be preventing lots of packages to make in > > testing, shouldn't it get some more attention? > > I was under the impression this bug was fixed in libtool 1.4.x. Is > that not the case? > i do not know wether it is fixed or not, this bug is still outstanding and its severity is set to "Serious policy violation", this prevents it making into testing (see update excuses). thanks > -Ossama > -- > Ossama Othman <[EMAIL PROTECTED]> > Distributed Object Computing Laboratory, Univ. of California at Irvine > 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 > -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
