Re: cdrtools alternatives
On Tuesday 15 August 2006 13:17, Nathanael Nerode wrote: > Florian Weimer wrote: > > * Nathanael Nerode: > >> In reality, as "user A", I switched to using cdrdao for making serious > >> audio CDs and CD-RWs, and for burning disks from .iso files: this uses > >> Schilling's scsilib, but not the rest of cdrecord. > > > > What about mkisofs? > > Heh -- that's a point. Actually, I don't use it when creating audio CDs > (for obvious reasons), and I don't usually create data CDs except by > burning *other people's* .iso files, since I use DVDs instead lately. > But I noticed that growisofs *does* use mkisofs as a backend. > > We definitely need a functional mkisofs in Debian. > > mkisofs is certainly part of cdrtools. But not of cdrecord. > > Nothing in mkisofs has weird conditions on the GPL, unlike other parts > of cdrtools (libscg, cdrecord.c), so it should be straightforward to > make a free fork. And it was originally written by Eric Youngdale. > > Likewise cdda2wav. It looks like the cdrecord package contains all the > 'problem areas', and the other packages built from the cdrtools source > package contain no problem areas. > > It's actually tempting to fork those two out as fully independent source > packages. They have little to do, code-wise, with CD recording. Right, forking up mkisofs only is one way to go, unless you find out that mkisofs code is a little bit of mess and find it hard to maintain, but it is not so bad anyway to stay there till a complete replacement matures enough to take it over. Fortunately there is a libburn (which contains libisofs) library to write optical dics recorders and iso filesystem-creators apps on the top of that like the recently packaged cdrskin. Unfortunately two libburn teams and source trees exist [1] which makes their users to maintain an enhanced snapshot for their own purposes, like cdrskin currently does. It currently lacks tao, audio, multi features, and writes CD-R and CD-RW only, but the upstream is active, very cooperative and tries to push improvements to the pykix fork of libburn. There is a nice attempt to post an empty hull of genisofs [2] (which is intended to be based on libisofs) to the pykix fork ticket system. Currently icculus's libburn is packaged in Debian, but it might be a good idea to switch to pykix fork at some point. While looking at #272644 it has been discovered that the open(2) manpage does not describe completely how O_EXCL option acts on a block device. I.e. what happens if an app using open(2) with O_EXCL | O_CREAT is run on the top of an old kernel which does not contains that O_EXCL functionaly. We found that post to lkml and I think that it would be nice to extend open(2) manpage with that important information. I will file a wishlist bug against manpage-dev at some point later. [1] the original effort http://icculus.org/burn/ (already packaged in Debian) and a recent fork at http://libburn.pykix.org [2] http://libburn.pykix.org/ticket/24 http://libburn.pykix.org/wiki/GenIsoFs [3] http://lkml.org/lkml/2006/2/5/137 -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Trouble building heimdal using
Hi list, I tried to build heimdal-0.7.2 using the testing source package for stable. The built itself went fine, but the splitting into subpackages failed. Also I have no clue how to fix the problem. So can anybody give me a tip what went wrong here? Since there is no 'binary:' target in rules, I think the problem is somewehere in the build system. TIA Rudi PS: Please CC me, since I'm not on the list The output of the built system: /bin/sh ./cf/install-catman.sh "/usr/bin/install -c -m 644" "mkdir -p -- ." "." "/home/ranft/sources/heimdal/heimdal-0.7.2.dfsg.1/debian/tmp//usr/share/man" '$section' make[4]: Leaving directory `/home/ranft/sources/heimdal/heimdal-0.7.2.dfsg.1' make[3]: Leaving directory `/home/ranft/sources/heimdal/heimdal-0.7.2.dfsg.1' make[2]: Leaving directory `/home/ranft/sources/heimdal/heimdal-0.7.2.dfsg.1' make[1]: Leaving directory `/home/ranft/sources/heimdal/heimdal-0.7.2.dfsg.1' dh_installdirs -pheimdal-docs make: *** No rule to make target `install', needed by `binary/heimdal-docs'. Stop. Versions: debian sarge cdbs = 0.4.32 make = 3.80+3.81.b3-1 debhelper = 5.0.10 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote: > And guess what? System tests are actually more reliable, especially > when the user tells you what the system is. You can simply flip to > compiling foo_linux.c or foo_solaris.c and go on your way. This will never work. Real life example from a couple of weeks ago: I wrote a program that was running happily on Sarge, then somebody wanted to build it on RHEL and failed because the UUID library on RHEL does not have uuid_unparse_lower(). And RHEL _is_ Linux and it is pretty heavily used in corporate environments. So instead of foo_linux.c you need foo_sarge.c, foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, which is just plainly unmanageable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ifupdown 'extra' package with network ({pre,post}) testing scripts
Hello Javier, * Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>, [2006-08-15 19:41 +0200]: > I have written and collected some network testing scripts in a new > 'ifupdown-extra' package which is right now available in > http://people.debian.org/~jfs/ifupdown-extra > > This package provides additional scripts for ifupdown to test for some common > problems when setting up interfaces: > > - interfaces without a link (admin can have that condition abort interface >setup if he wants the behaviour described in #120382) Very nice. The test could be added to ping-places.sh (provided by ifupdown as an example), otherwise mapping stanzas using it to choose a logical interface will try to ping addresses using an interface which may be down. What about putting the code which checks the link status in a separate script, so that it can be used elsewhere? > This package also provides 'network-test', a script to test the network > configuration status by checking: > - Interface status This feature is not working properly here. On line 229 you do a "echo $status | grep UP\>". When status contains something like "1: lo: mtu 16436 qdisc noqueue" it fails. I guess you may just grep for "UP". Thanks for the package! ciao, ema signature.asc Description: Digital signature
Re: Surpassing Microsoft quality
For me, there is no problem with OOo on sarge: ~$ uname -a Linux magic 2.6.8-3-686 #1 Sat Jul 15 10:32:25 UTC 2006 i686 GNU/Linux libfreetype62.1.7-2.5 openoffice.org-writer 2.0.3-1bpo1 from backports.org Regards, Ralph -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383316: ITP: fretsonfire -- game of musical skill and fast fingers
Package: wnpp Severity: wishlist Owner: Miriam Ruiz <[EMAIL PROTECTED]> * Package name: fretsonfire Version : 1.0.192 Upstream Author : Sami Kyostila <[EMAIL PROTECTED]> * URL : http://www.unrealvoodoo.org/ * License : GPL Description : game of musical skill and fast fingers Frets on Fire is a game of musical skill and fast fingers. The aim of the game is to play guitar with the keyboard as accurately as possible. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383349: ITP: nifticlib -- IO libraries for the NIfTI-1 data format
Package: wnpp Severity: wishlist Owner: Michael Hanke <[EMAIL PROTECTED]> * Package name: nifticlib Version : 0.3 Upstream Author : NIfTI Data Format Working Group * URL : http://niftilib.sourceforge.net/ * License : public domain Programming Lang: C Description : IO libraries for the NIfTI-1 data format Niftilib is a set of i/o libraries for reading and writing files in the NIfTI-1 data format. NIfTI-1 is a binary file format for storing medical image data, e.g. magnetic resonance image (MRI) and functional MRI (fMRI) brain images. The NIfTI format is supported by AFNI, FSL, SPM and others. NIfTI-1 is adapted from the widely used ANALYZE 7.5 file format in the hope that older non-NIfTI-aware software that uses the ANALYZE 7.5 format will still be compatible with NIfTI-1. Please note, that while the authors have place this software in the public domain, some files in the tarball contain a copyright statement. This has to be clarified. I have added support for shared libraries to the package. I'd be glad about feedback concerning the packaging as this is my first attempt of a shared library package. Cheers, Michael -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (600, 'testing'), (200, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libslang2 breaks jed
Hi, I've two problems with libslang2. The first is, the package libslang2 includes a patch that changes the behaviour of a function. But jed expects the function behaviour as given in the original slang2 library. I've reported this bug #369152, 80 days ago, but the maintainer does not react. The upstream maintainer (of jed and slang) John E. Davis is also interested in what this patch should do. And the second problem is, the dependency version for libslang2 calcuated by dh_shlibdeps is always 2.0.1-1 although the installed version is newer. Why? How can I change this? There were bug fixes in libslang2 since 2.0.1-1. I need a newer version than this. Thanks, Jörg. -- Macht besitzen und nicht ausüben ist wahre Größe. (Friedl Beutelrock) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ifupdown 'extra' package with network ({pre,post}) testing scripts
On Wed, Aug 16, 2006 at 02:36:52PM +0200, Emanuele Rocca wrote: > Hello Javier, Hi there. > > This package provides additional scripts for ifupdown to test for some > > common > > problems when setting up interfaces: > > > > - interfaces without a link (admin can have that condition abort interface > >setup if he wants the behaviour described in #120382) > > Very nice. > The test could be added to ping-places.sh (provided by ifupdown as an > example), otherwise mapping stanzas using it to choose a logical > interface will try to ping addresses using an interface which may be > down. Could do. > What about putting the code which checks the link status in a separate > script, so that it can be used elsewhere? It's pretty standalone right now. You just have to run it as root as this: # IFACE=eth0 /etc/network/if-pre-up.d/check-network-cable The meat is, however, in the check_status() functions so they could move elsewhere and create a script that used $1 instead. > > This package also provides 'network-test', a script to test the network > > configuration status by checking: > > - Interface status > > This feature is not working properly here. Yep, sorry, the network-cable test in that one is still flacky, it should reuse the code in the 'check-network-cable' script (i.e. use 'ip link show' and look for NO-CARRIER, or use mii-tool or ethtool). I've fixed and made available a new version up at people.debian.org (package version 0.2 now) Regard Javier signature.asc Description: Digital signature
Re: Surpassing Microsoft quality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mgr. Peter Tuharsky wrote: >Hi > > >I've been using Debian for 4 years because I felt confident about > it's quality. I've swallowed the ancient software in the name of > stability. I've been proud of security updates. I learned how to make > the desktop useful for human beings. > >Now, I have awaken because of bug 372719. Wine crashes, > OpenOffice.org 2.0 crashes upon saving a document. The bug was > introduced in "security update" of libfreetype. Identification of > problem was quick in OpenOffice.org community, and also in Debian. Just > apply the next security update that will fix the bug. IIRC, "security updates" do just (and *only*) that: fix *security* bugs, not *feature* bugs. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE447HS9HxQb37XmcRArZdAKCMI6WXvTp6I97fvbf07QhkAZRhlACgg89G o2p228cqYcBxKlaiHN7+XHo= =Zj7B -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Surpassing Microsoft quality
On Wed, Aug 16, 2006 at 04:31:51PM -0500, Ron Johnson wrote: > IIRC, "security updates" do just (and *only*) that: fix *security* > bugs, not *feature* bugs. they do fix bugs caused by regressions in security updates though. sean signature.asc Description: Digital signature
Not able to build a package with pbuilder
Hi all,
I am trying to use pbuilder to test a package I am about to prepare for
upload but no matter which way - pbuild as root or pdebuild inside
source tree, I try the result is always the same. When pbuilder is
trying to execure configure from inside the chroot is fails with the
error message below:
./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
CFLAGS="-Wall -g -O2" LDFLAGS="-Wl,-z,defs"
/bin/sh: ./configure: Permission denied
make: *** [config.status] Error 126
pbuilder: Failed autobuilding of package
Some of you have any idea for a solution?
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG keys:
michael rasmussen cc
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E
mir datanom net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir miras org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--
Having nothing, nothing can he lose.
-- William Shakespeare, "Henry VI"
pgpwdk95NTXTI.pgp
Description: PGP signature
Re: Not able to build a package with pbuilder
On Wed, Aug 16, 2006 at 11:57:21PM +0200, Michael Rasmussen wrote:
> I am trying to use pbuilder to test a package I am about to prepare for
> upload but no matter which way - pbuild as root or pdebuild inside
> source tree, I try the result is always the same. When pbuilder is
> trying to execure configure from inside the chroot is fails with the
> error message below:
>
> ./configure --host=i486-linux-gnu --build=i486-linux-gnu --prefix=/usr
> --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
> CFLAGS="-Wall -g -O2" LDFLAGS="-Wl,-z,defs"
> /bin/sh: ./configure: Permission denied
> make: *** [config.status] Error 126
> pbuilder: Failed autobuilding of package
>
> Some of you have any idea for a solution?
Try:
chmod +x configure
Looks to me like execute permission for configure probably isn't
set.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not able to build a package with pbuilder
On 2006-08-17 00:02:22, The Fungi wrote: Try: chmod +x configure Looks to me like execute permission for configure probably isn't set. In my source tree configure has execute permission but when building the deb-package I notice these warnings: dpkg-source: warning: executable mode 0755 of `configure' will not be represented in diffdpkg-source: warning: executable mode 0755 of `depcomp' will not be represented in diff dpkg-source: warning: executable mode 0755 of `install-sh' will not be represented in diff dpkg-source: warning: executable mode 0755 of `config.guess' will not be represented in diff dpkg-source: warning: executable mode 0755 of `missing' will not be represented in diff dpkg-source: warning: executable mode 0755 of `autogen.sh' will not be represented in diff dpkg-source: warning: executable mode 0755 of `config.sub' will not be represented in diff Could this be the problem? And if it is, does this not indicate there is conflict between pbuilder and dpkg-buildpackage? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -- Yoda: When nine hundred years old you reach, look as good you will not. Hmm? pgp7BjmTGxVdJ.pgp Description: PGP signature
Re: Not able to build a package with pbuilder
On (17/08/06 00:08), Michael Rasmussen wrote: > > On 2006-08-17 00:02:22, The Fungi wrote: > > > >Try: > > > > chmod +x configure > > > >Looks to me like execute permission for configure probably isn't > >set. > In my source tree configure has execute permission but when building > the deb-package I notice these warnings: > You could see if chmod u+x configure in your debian/rules fixes it, but it shouldn't be necessary. > > Could this be the problem? And if it is, does this not indicate there > is conflict between pbuilder and dpkg-buildpackage? > I think I remember someone metioning this before, and it turned out to be caused by something that seemed completely unrelated. Unfortuanately I cannot remember what. Helpful eh? James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not able to build a package with pbuilder
On Thu, 17 Aug 2006, Michael Rasmussen wrote: > On 2006-08-17 00:02:22, The Fungi wrote: > > chmod +x configure > > > >Looks to me like execute permission for configure probably isn't > >set. > In my source tree configure has execute permission but when building > the deb-package I notice these warnings: > > dpkg-source: warning: executable mode 0755 of `configure' will not be > represented in diffdpkg-source: warning: executable mode 0755 of > `depcomp' will not be represented in diff > dpkg-source: warning: executable mode 0755 of `install-sh' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `config.guess' will not > be represented in diff > dpkg-source: warning: executable mode 0755 of `missing' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `autogen.sh' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `config.sub' will not be > represented in diff > > Could this be the problem? And if it is, does this not indicate > there is conflict between pbuilder and dpkg-buildpackage? It means that your upstream is having issues; configure should be +x in the orig.tar.gz. Since it's not, you can either "sh ./configure;" or chmod +x, then ./configure in debian/rules. I'd suggest the first, because the second will give you at least one of the warnings above. Don Armstrong -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not able to build a package with pbuilder
On 2006-08-17 00:53:16, James Westby wrote: You could see if chmod u+x configure in your debian/rules fixes it, but it shouldn't be necessary. How I am going to do that? configure is in the tar.gz.diff file and from what I know debian/rules has no access to that file? -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -- Q: What happens when four WASPs find themselves in the same room? A: A dinner party. pgpXLsTAXsXlY.pgp Description: PGP signature
Re: Not able to build a package with pbuilder
On (17/08/06 00:57), Michael Rasmussen wrote: > > On 2006-08-17 00:53:16, James Westby wrote: > > > >You could see if chmod u+x configure in your debian/rules fixes it, > >but > >it shouldn't be necessary. > > > How I am going to do that? configure is in the tar.gz.diff file and What file is that? Do you mean diff.gz or orig.tar.gz? Either way it will be in the unpacked source. > from what I know debian/rules has no access to that file? It does have access, as it is able to ./configure James -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not able to build a package with pbuilder
On 2006-08-17 00:54:41, Don Armstrong wrote: It means that your upstream is having issues; configure should be +x in the orig.tar.gz. In this special situation orig.tar.gz is not to blame since orig.tar.gz is not prepared to use autotools in which case configure does not exist in upstream. I have transformed the upstream to using autotools, and this is the reason for my problems. Is there no way atoll I can instruct dh_make to maintain executable permissions in diff.gz? Since it's not, you can either "sh ./configure;" or chmod +x, then ./configure in debian/rules. I'd suggest the first, because the second will give you at least one of the warnings above. Your first solution is the simplest so for now I will stick to that. Thanks. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -- Q: What happens when four WASPs find themselves in the same room? A: A dinner party. pgppJ1nkethNK.pgp Description: PGP signature
Re: Not able to build a package with pbuilder
On 2006-08-17 01:53:59, Junichi Uekawa wrote: It's the way diff/patch works. They don't preserve execute permissions. I have realised that and I am opting for Don Armstrong solution which solves the matter. Thanks. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael rasmussen cc http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xD3C9A00E mir datanom net http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C mir miras org http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917 -- Alas, how love can trifle with itself! -- William Shakespeare, "The Two Gentlemen of Verona" pgpQZmcvpVfES.pgp Description: PGP signature
Re: Not able to build a package with pbuilder
> In my source tree configure has execute permission but when building > the deb-package I notice these warnings: > > dpkg-source: warning: executable mode 0755 of `configure' will not be > represented in diffdpkg-source: warning: executable mode 0755 of > `depcomp' will not be represented in diff > dpkg-source: warning: executable mode 0755 of `install-sh' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `config.guess' will not > be represented in diff > dpkg-source: warning: executable mode 0755 of `missing' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `autogen.sh' will not be > represented in diff > dpkg-source: warning: executable mode 0755 of `config.sub' will not be > represented in diff > > Could this be the problem? And if it is, does this not indicate there > is conflict between pbuilder and dpkg-buildpackage? It's the way diff/patch works. They don't preserve execute permissions. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: afraid to build from source?
Peter Samuelson <[EMAIL PROTECTED]> writes: > [Goswin von Brederlow] > It's true that you can, but it's no excuse. Upstream has reason to > ship pre-built automake/autoconf output, because historically, random > users could be expected to have 'make' and a C compiler, but couldn't > be expected to have autoconf. In Debian we are not constrained by > that, we should not have to avoid building packages entirely from > source. I never said it is an excuse. It just how it is and convenient given how fragile auto* is. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: > On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote: > > > And guess what? System tests are actually more reliable, especially > > when the user tells you what the system is. You can simply flip to > > compiling foo_linux.c or foo_solaris.c and go on your way. > > This will never work. Real life example from a couple of weeks ago: I > wrote a program that was running happily on Sarge, then somebody wanted > to build it on RHEL and failed because the UUID library on RHEL does not > have uuid_unparse_lower(). So you chose to use a function not reliably available. Sounds like bad planning to me. > And RHEL _is_ Linux and it is pretty heavily used in corporate > environments. So instead of foo_linux.c you need foo_sarge.c, > foo_etch.c, foo_rhel.c, foo_opensuse.c and probably a dozen more, > which is just plainly unmanageable. No, you figure out what the base system requirement is, and write to that. I can guarantee you that there's a lot more difference between AIX and "Linux" than there is between RHEL 3.x and Debian sarge, not to even mention non-Unix platforms. None-the-less, code can be written that runs on all of them. You figure out where the incompatability points are, and you write functions to mask them. Of course the functions themselves have #ifdefs (or some other way of controlling compilation), but you get it *out* of your main code base. And yes, you could use autoconf to control those generic functions. But usually it's overkill. If you actually understand enough about where the edges of portability are, you don't need autoconf, and if you don't, autoconf doesn't help, because you waste your time checking for things that are universally available (memcpy(), string.h) and don't have clue about variances in signal handling, or why assuming "char" is signed is a bad idea. I spend quite a bit of my life working on non-Linux platforms (as well as a variety of Linux ones). I've built *lots* of free software on these platforms. My experience is that the ones whose build instructions say "edit the makefile to pick your platform and compiler" compile and work, and when they don't, they're easy to fix. The ones that use autoconf tend to blow up on non-Linux[1], in ways that are hard to debug and damn near impossible to fix. Steve [1] Prior to the widespread adoption of Linux, this was less true; presumably the developers actually used non-Linux systems. -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
Steve Greenland <[EMAIL PROTECTED]> wrote: > On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote: >> This will never work. Real life example from a couple of weeks ago: I >> wrote a program that was running happily on Sarge, then somebody wanted >> to build it on RHEL and failed because the UUID library on RHEL does not >> have uuid_unparse_lower(). > > So you chose to use a function not reliably available. Sounds like bad > planning to me. Yeah, wanting to use functionality when it's available is always a dreadful idea. Far better to reimplement it locally in order to ensure that we have more copies of it to fix should there ever be any sort of security flaw. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WTF ? (Fwd: Your message to Yaird-devel awaits moderator approval)
> "Thomas" == Thomas Weber <[EMAIL PROTECTED]> writes: Thomas> How is that different from a non-responsive maintainer (in Thomas> which case you don't even know that the message arrived on Thomas> his mail system)? First you need to define "non-responsive maintainer". Depending on the circumstances, the maintainer might be MIA, and the appropriate procedures need to be followed. However, there are differences: * In one case you can usually assume the maintainer got the message, in the other case you practically got confirmation that the message didn't get through. * If the maintainer doesn't respond, you can always send a ping, and find out if he/she replies. * If you get a warning message from a mailing list, then sending a ping message won't do any good, the same thing will happen. * The warning message seems rude. I took the effort to email Debian a bug report - why should I get spammed with this meaningless message in response? * The warning message implies that people who send bug reports to Debian must also subscribe to upstream mailing lists. This is unacceptable (IMHO). I already subscribe to far too many mailing lists. * It gives the impression that the Debian maintainers aren't interested in receiving bug reports or improving the quality of their packages. Yes, both cases are bad and we should be working to eliminate them. Attached is a bounce message I just got recently from a bug report I just filled. --- Begin Message --- Your mail to 'Pkg-mediawiki-devel' with the subject Bug#383130: mediawiki1.7: rss feed item should contain a guid element Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.alioth.debian.org/mailman/confirm/pkg-mediawiki-devel/1be83dbece0b34e14e5525b3961c6a36e2267d62 --- End Message --- -- Brian May <[EMAIL PROTECTED]>
Re: Trouble building heimdal using
> "Rüdiger" == Rüdiger Ranft <[EMAIL PROTECTED]> writes: Rüdiger>cdbs = 0.4.32 My first guess would be to try back porting cdbs first. -- Brian May <[EMAIL PROTECTED]>
Bug#383398: ITP: tptest3 -- A suite for testing bandwidth
Package: wnpp Severity: wishlist Owner: Michael Rasmussen <[EMAIL PROTECTED]> * Package name: tptest3 Version : 3.1.7 Upstream Author : Ragnar Loenn <[EMAIL PROTECTED]> * URL : http://tptest.sourceforge.net * License : GPL Programming Lang: C Description : A suite for testing bandwidth DESCRIPTION The purpose with TPTEST is to allow users to measure the speed of their Internet connection in a simple way. TPTEST measures the throughput speed to and from various reference servers on the Internet. The use of TPTEST may help increase the consumer/end user knowledge of how Internet services work. This package include: 1) The reference server. This is the server users connects to. 2) The master server. The is the server users query for and address of a testserver. 3) A very minimal cli client to test the rererence server. The package provides this in three binary packages. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=da_DK, LC_CTYPE=da_DK (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383401: ITP: keytouch -- easily configure extra function keys in multimedia keyboards
Package: wnpp Severity: wishlist Owner: Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> * Package name: keytouch Version : 2.2.0 Upstream Author : Marvin Raaijmakers <[EMAIL PROTECTED]> * URL : http://keytouch.sourceforge.net/index.html * License : GPL Programming Lang: C Description : easily configure extra function keys in multimedia keyboards Kaytouch allows you to define, for every individual function key, what to do if it is pressed. KeyTouch version 2 is designed for Linux kernel 2.6 and is the first program of its kind that perfectly works together with kernel 2.6. Keytouch 2.1.4 is already packaged for Ubuntu. Said packaging will be used as a starting point for the Debian package. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Remove cdrtools
Steve Greenland <[EMAIL PROTECTED]> writes: > You figure out where the incompatability points are, and you write > functions to mask them. Of course the functions themselves have > #ifdefs (or some other way of controlling compilation), but you get it > *out* of your main code base. Gee sounds like a _perfect_ application of ... autoconf! > I spend quite a bit of my life working on non-Linux platforms (as well > as a variety of Linux ones). I've built *lots* of free software on these > platforms. My experience is that the ones whose build instructions say > "edit the makefile to pick your platform and compiler" compile and work, > and when they don't, they're easy to fix. The ones that use autoconf > tend to blow up on non-Linux[1], in ways that are hard to debug and damn > near impossible to fix. This is a cultural artifact (of a monoculture made possible by the relative dominance of linux in its niche), not a result of using autoconf. [In the early days of linux, it was much, _much_ worse, because not only didn't they use autoconf, they didn't even _try_ to be portable, simply assumed everything was exactly like the exact linux distribution they happened to be using.] Programs that work well with "edit the makefile and define SYS to be sys-FOO.c" style tend to program to the lowest common denominator, because doing anything else simply becomes too painful with this style of portability. This is fine for some apps (and indeed autoconf supports this sort of thing quite well), but in cases where you _need_ to use more esoteric functionality, it quickly becomes a real pain; autoconf's emphasis on finer-granularity helps considerably (though it's always going to be a pain). The main problem with your argument is that you seem to be looking at poorly written programs that use autoconf, and jumping to the conclusion that autoconf is the reason for the poor programming -- it's not. Bad programmers made a hash of it no matter what style of portability they choose. -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove cdrtools
[Steve Greenland] > My experience is that the ones whose build instructions say "edit the > makefile to pick your platform and compiler" compile and work, and > when they don't, they're easy to fix. The ones that use autoconf tend > to blow up on non-Linux[1], in ways that are hard to debug and damn > near impossible to fix. This, as you note in your footnote, is probably attributable entirely to whether the developers actually have a clue that there is more to Unix than Linux/i386. The style of uncommenting defines in a Makefile, versus autoconf, is an _effect_, not a cause - the effect only _appears_ to be causal because the Unix-ignorant don't tend to use the former style. There is, either way, no substitute for awareness of portability issues, and no substitute for actual development experience on multiple Unix platforms. As for useless autoconf tests - have you looked at how autoconf is used? You pick the tests you think you need. It's not like the system forces you to use a certain range of obsolete baseline tests. A huge number of test macros are provided, but nobody forces you to use them. signature.asc Description: Digital signature
Re: Is inability to operate with root read-only (and separate /etc, /dev, etc) a bug or design decision?
[Philipp Matthias Hahn] > Which doesn't work because of linux-utils-2.12r/mount/fstab.c:55 As I recall, Andries (util-linux upstream) produced, at least a year ago, a kernel patch which allows the kernel to store an extra string of user data from 'mount', and display it in /proc/mounts, so that neither mount nor umount need bother with /etc/mtab. In other words, upstream is well aware of this issue and has a solution ready to implement, if only someone would merge the patch into the kernel. And if only I could actually find the lkml reference to this. signature.asc Description: Digital signature
Problems with security updates (was: Surpassing Microsoft quality)
> Now, I have awaken because of bug 372719. Wine crashes, OpenOffice.org > 2.0 crashes upon saving a document. The bug was introduced in > "security update" of libfreetype. Identification of problem was quick > in OpenOffice.org community, and also in Debian. Just apply the next > security update that will fix the bug. > > Not that easy. It's 2 months now and bug still there. Dear Mgr Tuharsky, The Debian bug tracking system contains pseudo-packages to report such problems to the relevant persons. For your case, the pseudo-package is "security.debian.org". http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=security.debian.org By sending your message directly to a wider audience, you give the impression that its purpose is to ashame the responsible persons, not to inform them, especially as you added remarks about abandonning Debian because of you are not satisfied of the quality of their work. In the meantime before the breakage is resolved, please note the workaround published in the bug you cited. Best regards, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not able to build a package with pbuilder
Michael Rasmussen <[EMAIL PROTECTED]> writes: > On 2006-08-17 01:53:59, Junichi Uekawa wrote: >> >> It's the way diff/patch works. They don't preserve execute >> permissions. >> > I have realised that and I am opting for Don Armstrong solution which > solves the matter. Thanks. You could run autoconf from within rules and have configure be created during build. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Removing moderation on Alioth lists
Le Thu, Aug 17, 2006 at 10:52:52AM +1000, Brian May a écrit : > Subject: Your message to Pkg-mediawiki-devel awaits moderator approval > > > The reason it is being held: > > Post by non-member to a members-only list > Dear all, In the case of the mail list of the packaging project of debian-med, we decided to remove moderation after reading this thread. It took us some time to figure out how to do it in mailman. For the other persons unfamiliar with mailman, here is what to do: * In Privacy options... / Sender filters, set "generic_nonmember_action" to "accept". * In Privacy options... / Recipient filters, set "require_explicit_destination" to "no". Hope that helps, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Surpassing Microsoft quality
If the bug, that You call *feature*, has been introduced by *security updates*, how do they get fixed then? Does it get fixed ever? Ron Johnson wrote / napísal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mgr. Peter Tuharsky wrote: Hi I've been using Debian for 4 years because I felt confident about it's quality. I've swallowed the ancient software in the name of stability. I've been proud of security updates. I learned how to make the desktop useful for human beings. Now, I have awaken because of bug 372719. Wine crashes, OpenOffice.org 2.0 crashes upon saving a document. The bug was introduced in "security update" of libfreetype. Identification of problem was quick in OpenOffice.org community, and also in Debian. Just apply the next security update that will fix the bug. IIRC, "security updates" do just (and *only*) that: fix *security* bugs, not *feature* bugs. - -- Ron Johnson, Jr. Jefferson LA USA Is "common sense" really valid? For example, it is "common sense" to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that "common sense" is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE447HS9HxQb37XmcRArZdAKCMI6WXvTp6I97fvbf07QhkAZRhlACgg89G o2p228cqYcBxKlaiHN7+XHo= =Zj7B -END PGP SIGNATURE-
Re: Problems with security updates -apologize
Charles, I agree that my message has been very emotional. I'm sorry for that and I apologize to all I have hurt. I really lost my nerves. You can imagine that from the fact, that I'm active member of some 15+ GNU bug/mailing lists and really don't need more. For 4 years with Debian, nothing has ever provoked me so much (and there has been much that easily could, especially in era of Woody :-) You're right by all means. I must only point out that the problem has been reported and traced in all the right places -both debian bugtacker and ooo issuezilla. It's been the lack of any further action, and strong powerless feeling, that provoked me to such a miserable action as the message I sent. I couldn't use the OOo2.0 for nearly 2 months, and however I am able to search bug tracker and to apply workarounds, I can imagine people that lack the technical skills to do that. The blame I bringed up here, You can consider partially theirs voice, that is hard to hear otherwise. I think it's better to take blame here in developement mailing list, than take it from the ordinary users, because they're usually silent, and if they spoke ever, it'd be already late. I know that Debian is a large project and the fact that it works the way it does, is kind of miracle. However, the bad problem on bad place can override this all.. Peter Charles Plessy wrote / napísal(a): Now, I have awaken because of bug 372719. Wine crashes, OpenOffice.org 2.0 crashes upon saving a document. The bug was introduced in "security update" of libfreetype. Identification of problem was quick in OpenOffice.org community, and also in Debian. Just apply the next security update that will fix the bug. Not that easy. It's 2 months now and bug still there. Dear Mgr Tuharsky, The Debian bug tracking system contains pseudo-packages to report such problems to the relevant persons. For your case, the pseudo-package is "security.debian.org". http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=security.debian.org By sending your message directly to a wider audience, you give the impression that its purpose is to ashame the responsible persons, not to inform them, especially as you added remarks about abandonning Debian because of you are not satisfied of the quality of their work. In the meantime before the breakage is resolved, please note the workaround published in the bug you cited. Best regards,
Re: WTF ? (Fwd: Your message to Yaird-devel awaits moderator approval)
Hi, Am Donnerstag, den 17.08.2006, 10:52 +1000 schrieb Brian May: > * In one case you can usually assume the maintainer got the message, > in the other case you practically got confirmation that the message > didn't get through. > > * If the maintainer doesn't respond, you can always send a ping, and > find out if he/she replies. > > * If you get a warning message from a mailing list, then sending a ping > message won't do any good, the same thing will happen. I would sum up all these reasons as "if the message doesn't come through, the maintainers are MIA". Just for the record: for every message held for approval, the moderators get an email saying so. It's not like they have to check this manually. > * The warning message seems rude. I took the effort to email Debian a > bug report - why should I get spammed with this meaningless message > in response? I actually consider this a configuration issue. However, I have not yet seen a possibility to waive BTS messages through (which would be really helpful). I'm looking into the documentation right now. > * The warning message implies that people who > send bug reports to Debian must also subscribe to upstream mailing > lists. This is unacceptable (IMHO). I already subscribe to far too many > mailing lists. I don't think that the message implies that. At least, you are the first one to bring this up. > * It gives the impression that the Debian maintainers aren't > interested in receiving bug reports or improving the quality of > their packages. Well, I think it gives the impression that the lists' moderators care about not filling the subscribers' inboxes with even more spam; I don't have hard numbers (I don't count the messages), but my feeling is that > 50% of all messages are spam. I suggest you have a look at some not-so-much used lists at lists.debian.org (June 2006 of debian-consultants is a pretty good example). These lists look as if nobody cared what happens with them. Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
