Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
Hello, On Wed, 22 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: I have uploaded a new version with the suggested fixes. Following your sugestion I used 3:4.20-4~1 as version. If you consider it worthy of upload, please change it to -4. And please build with -v3:4.20-2 Thanks for pointing this (-v3:4.20-2) out or I might have forgotten! http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~1.dsc Package looks fine. I'm currently updating my local pbuilder base and will upload when that is done. I've been playing with both kinds of repositories, with and without upstream sources, in my packages, but I'm not sure yet which workflow is easier. Do you have some description on pros/cons from others, to help decide? I have moved towards repositories that contain *only* the debian/ directory. I find it easier to keep track of my own changes that way. As far as I know this is the recommended approach. It is relatively easy to setup something like debian/rules get-orig-source to get the upstream source (though I have not done this for some of my packages!). Regards, Kapil. -- signature.asc Description: Digital signature
Re: How to deliver an binary file
On Mon, Aug 20, 2007 at 09:51:49AM +1000, Ben Finney wrote: If that's the case, what they distribute isn't free software — unless any recipient can get that source. Certainly, for it to be included in Debian, we need to distribute the *entire* corresponding source form of the work. Is this then justification for putting the sfd in the orig and repacking with a -dfsg suffix to the upstream version? -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
Hi, Felipe. On Aug 18 2007, Felipe Sateler wrote: This way, you have automatic update of the authors when updating to a new upstream version. This is, indeed, a good way of managing projects with large numbers of contributors. Regards, Rogério. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On handling the AUTHORS file (was: Re: RFS: gconf-cleaner - GConf database cleaner)
On Aug 18 2007, Felipe Sateler wrote: This is a bug in the xine-lib package because it doesn't ship the AUTHORS file, even though copyright references it. Filed as #438677. Thanks for letting me know about this. It is quite welcome. Regards, Rogério. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: tagtool
On Aug 22 2007, Kartik Mistry wrote: It builds these binary packages: tagtool- Tool to tag and rename MP3 and Ogg Vorbis files What does this tool gives the user that, say, easytag (one of the most powerful tag programs around that I know of) doesn't? Regards, Rogério. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Note: it doesn't need the customised version to be *installed* --- all it needs is the .so somewhere private where it can find it. I suppose the worst-case scenario is where I have to ship a copy of the glibc source along with the plasticfs source and build it there... which is pretty horrible. Not the least of which is trying to keep the various version in sync. Of course, my build process *could* just do 'apt-get source glibc' and patch the result... Is there a smarter way of doing things? - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs. --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzeaCf9E0noFvlzgRAq4/AKCZ7Vl1HXSN2pPXvGNzY1qzLPm/OgCfXaI0 z7KEvCzTsEakF9Z3QKrXp1A= =aw6V -END PGP SIGNATURE-
Re: Package requiring a customised version of another package
On Thu, Aug 23, 2007 at 08:56:50PM +0100, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Please can you give the details of why this is necessary? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Please can you give the details of why this is necessary? It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() calls open() --- it does so using a hidden private interface, which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. Or so the plasticfs docs say --- I'm sure this can be worked around, since fakeroot and fakechroot manage it, but I wouldn't know how to do that. Also, I'm working on the assumption that upstream at least know something about what they're talking about... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs. --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzfuLf9E0noFvlzgRAiq/AJ0XJAopwbtk0Kmw+0FKfht8NL1YZgCgkT2b 9PsElxgRWVm+0ccZbf+WpEg= =O/mh -END PGP SIGNATURE-
Re: Package requiring a customised version of another package
On Thu, Aug 23, 2007 at 10:26:35PM +0100, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Please can you give the details of why this is necessary? It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() calls open() --- it does so using a hidden private interface, Right, aliases are used when public functions are called internally (I'm not sure the rationale). which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. I still don't understand why? Or so the plasticfs docs say --- I'm sure this can be worked around, since fakeroot and fakechroot fakeroot is just an LD_PRELOAD.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of another package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. I still don't understand why? I *presume* so that plasticfs can just override open() and not have to worry about overriding fopen() and getpwent() and tmpfile() and all the other glibc functions that call open() internally. - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs. --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzgTkf9E0noFvlzgRAiWFAKCdDIRZ5Ck9rzyUz0R41OcSCrFZHgCdFA3U /Ep0TftHwqqas2W08YyuFXQ= =Bszw -END PGP SIGNATURE-
Re: Package requiring a customised version of libc6
On Thu, 23 Aug 2007 22:26:35 +0100 David Given [EMAIL PROTECTED] wrote: Please can you give the details of why this is necessary? It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() calls open() --- it does so using a hidden private interface, which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. Or so the plasticfs docs say --- I'm sure this can be worked around, since fakeroot and fakechroot manage it, but I wouldn't know how to do that. Also, I'm working on the assumption that upstream at least know something about what they're talking about... As Debian maintainer, you need to know a whole lot more about why upstream decided to work this way before adding a duplicate glibc to the archive. 1. Investigate fakeroot and fakechroot. Find out how they work. If you cannot work this out, don't package plasticfs. You are to be the Debian maintainer for this package, you MUST understand enough about how it works to be able to justify both having the package in Debian in the first place and your own packaging decisions. You can't just transfer the blame to the mentors list and say I have almost no idea how or why *my* package requires a duplicate glibc but this is how I was told to do it on mentors.debian.net. Do the work and come back to the list with a detailed reasoning for what is a MAJOR packaging decision. This isn't yet another customised version of a package it is a COPY of GLIBC! Such things are not to be done lightly - especially when you appear to have very little understanding of why this would even be desirable. 2. Find out precisely why your package needs this interface - maybe it is just that upstream are trying to get around problems that don't apply to the Debian package, maybe there were problems building the upstream code on Fedora or OSX or something. Find out if any upstream developers use Debian. 3. Detail *PRECISELY* why your package needs this interface - what it does with it, why it cannot use the standard interface, which calls are made and why (including the filenames, function names and line numbers in the source code). Which parts of the functionality of the package are affected. How other packages deal with the same issue and *detailed* explanations of why your package cannot use those methods. What are the alternatives, which parts of the codebase need patching to use the standard glibc? Do the proposed patches work? Why not? 4. Do not assume that upstream have any idea of what happens inside a distribution. Upstream cares about upstream generally - they care about the .tar.gz, not the .deb or .rpm. Find out if there is a .rpm or maybe a gentoo emerge build. Work out how they do things. This ties into (3) because if you know which distro(s) upstream developers are using, you know where to start looking at how the upstream code is packaged elsewhere. 5. You will need a watertight argument to persuade the glibc maintainers that Debian needs a slightly customised version that will *always* be out of sync and out of step with the Debian package. Generally, such versions are simply BAD IDEAS that have not been thought through. Do *not* approach the glibc maintainers for advice at this stage - find out a whole lot more if you want to be taken seriously. Describing your main reason as a hack is not going to win you any friends amongst the glibc maintainers and you DO need to get them on your side. If you cannot provide sufficient, detailed, arguments to put your case, you could find an RC bug appearing against your package before it even leaves NEW. There is zero point searching for a sponsor for a package that is likely to be rejected upon upload so do your homework beforehand and work out if, how and why you need to do things this way. Then double-check all your arguments and finally, throw out all your reasons to copy glibc and find a way to work with the standard glibc. :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpTyLnKOky9G.pgp Description: PGP signature
Re: Package requiring a customised version of libc6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Williams wrote: [...] Do the work and come back to the list with a detailed reasoning for what is a MAJOR packaging decision. This isn't yet another customised version of a package it is a COPY of GLIBC! Don't shout at me, please. Yes, I am entirely aware of all the issues you raise. However, at this point I am still collecting information. I have no intention of doing *anything* until I know exactly what's going on. Currently I am merely trying to figure out whether upstream's idea of using a customised glibc is possible on Debian; I suspect it's not, but as I haven't actually received an answer to my question yet, it's still rather up in the air... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs. --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzht7f9E0noFvlzgRAgufAJ45Bb0AsCfnWnkAsLEmozlEZrPsRgCfZO3z k6pVrsqtl3pSWbObn5drGWY= =4jv2 -END PGP SIGNATURE-
Re: Package requiring a customised version of libc6
On Fri, 24 Aug 2007, David Given wrote: Currently I am merely trying to figure out whether upstream's idea of using a customised glibc is possible on Debian It's always possible to do so. However, actually doing so requires that you convince the security team, the maintainer(s), and the release managers that having a duplicate copy of the glibc code and duplicating the associated work for any bugs found in glibc is worth the extra effort. The people who have responded to you so far strongly suspect that it's not worth the effort, but without knowing why the glibc we already distribute can't be used, it's hard for us to give you a definitive answer. Don Armstrong -- If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of libc6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Armstrong wrote: [...] The people who have responded to you so far strongly suspect that it's not worth the effort, but without knowing why the glibc we already distribute can't be used, it's hard for us to give you a definitive answer. *nods* As far as I can tell --- I've contacted upstream to confirm this --- what plasticfs wants to do is to override the underlying system calls (or at least, the functions that call them) that access the file system. Unfortunately, those system calls are not exposed by default, so plasticfs wants a tweaked glibc in which they are exposed. By overriding the system calls rather than the higher-level functions, it means that plasticfs doesn't have to override the higher-level functions --- they work automatically. fakeroot and fakechroot appear to operate by overriding *all* glibc functions that might access the file system. I've had a look at the code... it's unpleasant. There are a lot of functions that might do this, and not all of them are easily overridable, and quite a lot of them are rather obscure. (I'd never even heard of ftw() and nftw() before now.). This makes it much harder to catch coverage issues. A function that isn't wrapped will work on the real file system, rather than the virtual one. I notice that fakechroot doesn't wrap getpwent(), for example --- which means it'll always use the *real* /etc/passwd, rather than the emulated one. This could be intentional, but as it's not mentioned in the docs I suspect it's a bug. I've given up on the replacing-glibc idea; it was pretty horrible anyway. Unfortunately, the alternatives seem just as horrible, in different ways... - -- ┌── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─── http://www.cowlark.com ─── │ │ There does not now, nor will there ever, exist a programming language in │ which it is the least bit hard to write bad programs. --- Flon's Axiom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGziWjf9E0noFvlzgRAmPdAJkBBRbIetG6x/T23fKqDZtetrir+wCeP7fY t5NJukVanIgk7i8iZSW2W9E= =pOkz -END PGP SIGNATURE-
