Re: ITR: varkon (updated package)
Matthias Julius [EMAIL PROTECTED] writes: Matthias Julius [EMAIL PROTECTED] writes: I will address the other points you mentioned earlier and also the issues Erik mentioned tonight (hopefully, maybe tomorrow) when I get home. OK, it took a little longer than two days, but I had a lot of things going on. And I fixed a couple more little issues I discovered myself. I have tried to address all of your concerns except the varkon: arch-dep-package-has-big-usr-share message from lintian which I want to take care of in a later upload. Also I havn't come up with example files, yet. I am currently trying to do that. This beast is trickier than I thought. I have started a discussion on the Varkon mailing list and confirmed that the files the package puts in /usr/share/varkon are in fact arch specific. I will therefore move them to /usr/lib/varkon. Also, Varkon is not 64bit safe. I have noticed myself that the compiler complains a lot about castings between integers and pointers of different size when I build it for amd64. When asked on the list upstream also confirmed that Varkon currently does not support 64bit archs. What is the best way to deal with that issue until it is fixed properly upstream? Should I just disable all 64bit architectures for the varkon package? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lighttpd1.5
Hi, I've packaged lighttpd1.5 package (svn r2048), closing this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460433 and uploaded it to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=lighttpd1.5 Can you look, if it is good packaged? Is it possible to upload it to Debian in experimental or unstable section? The reason, that I packaged it is that we need to use lighttpd1.5 in production, but Debian lighttpd maintainers build package only for 1.4version. -- Ilya M. Slepnev
Re: ITR: varkon (updated package)
Hi Matthias, Matthias Julius [EMAIL PROTECTED]: Also, Varkon is not 64bit safe. I have noticed myself that the compiler complains a lot about castings between integers and pointers of different size when I build it for amd64. When asked on the list upstream also confirmed that Varkon currently does not support 64bit archs. What is the best way to deal with that issue until it is fixed properly upstream? Should I just disable all 64bit architectures for the varkon package? IMO excluding of architectures is good if the program makes no sense on it, e.g. because of missing hardware. In your case it is a problem of unportable code, you should fix it before. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, auch wieder 2008 * Info: http://www.linux-info-tag.de/* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: terminator
I still looking for a sponsor, can someone take a look at it? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460317 On Mon, 2008-01-14 at 18:35 +, Neil Williams wrote: On Mon, 14 Jan 2008 13:23:18 -0500 Nicolas Valcárcel [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for my package terminator. * Package name: terminator Version : 0.7-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Please don't waste my time with junk - fill in the above details. terminator - Multiple GNOME terminals in one window ? Haven't you used tabs in gnome-terminal ? Include the long description and clarify why this package is desirable in Debian. -- aka nxvl key fingerprint: E140 4CC7 5E3C B6B4 DCA7 F6FD D22E 2FB4 A9BA 6877 gpg --keyserver keyserver.ubuntu.com --recv-keys A9BA6877 Yo uso Software Libre y tu? signature.asc Description: This is a digitally signed message part
Re: Using symbols files
On Wed, Jan 16, 2008 at 11:47:23AM -0800, Russ Allbery wrote: the symbols file. (My recommendation would be to drop the Debian revision on all the versions in the symbols file for zlib1g, on the grounds that the introduction of new symbols was an upstream change so any package of, JFTR this has already been done - it's basically just a case of getting there too early. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pydict (Updated package)
Pierre Habouzit wrote: On Thu, Jan 17, 2008 at 02:38:58AM +, Barry deFreese wrote: Dear mentors, I am looking for a sponsor for my package pydict. * Package name: pydict Version : 0.2.5.1-3.2 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : text It builds these binary packages: pydict - an English/Chinese Dictionary written with python/gtk The upload would fix these bugs: 405895 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pydict - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pydict/pydict_0.2.5.1-3.2.dsc FWIW (and sorry I don't have the time to look at it right now, I'll do if nobody did before next Wednesday) I believe the package should be orphaned, and packaging upgraded in the name of QA work. CHeers, Pierre, Thanks I agree. Though it sounds like the maintainer might be back from a long absence. I'd be happy to update the package too but I keep getting told I shouldn't do that on an NMU. Thanks again, Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lighttpd1.5
On Thu, Jan 17, 2008 at 08:07:22PM +, Pierre Habouzit wrote: On Thu, Jan 17, 2008 at 07:23:40PM +, Ilya M. Slepnev wrote: Hi, I've packaged lighttpd1.5 package (svn r2048), closing this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460433 and uploaded it to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=lighttpd1.5 Can you look, if it is good packaged? Is it possible to upload it to Debian in experimental or unstable section? The reason, that I packaged it is that we need to use lighttpd1.5 in production, but Debian lighttpd maintainers build package only for 1.4version. Please just don't sponsor this upload. lighttpd is nowhere near production quality, and debian won't upload it. I don't know why I overlooked this bug report, it seems my procmail filter needs serious tweaking, but (1) there is absolutely no valid reasons to have 2 separate lighttpd packages and (2) the 1.5 version is not stable enough. Okay, I god confused with lighttpd 2.0, 1.5 is just the next in line in the same generation as 1.4.18 (currently in debian), and 1.5 is _NOT_ released yet. So packaging it is nonsense. I'm closing the bug, we don't package unreleased software, we only backport patches if needed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOUWIIZjjtc.pgp Description: PGP signature
Re: lighttpd1.5
On Thu, Jan 17, 2008 at 07:23:40PM +, Ilya M. Slepnev wrote: Hi, I've packaged lighttpd1.5 package (svn r2048), closing this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460433 and uploaded it to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=lighttpd1.5 Can you look, if it is good packaged? Is it possible to upload it to Debian in experimental or unstable section? The reason, that I packaged it is that we need to use lighttpd1.5 in production, but Debian lighttpd maintainers build package only for 1.4version. Please just don't sponsor this upload. lighttpd is nowhere near production quality, and debian won't upload it. I don't know why I overlooked this bug report, it seems my procmail filter needs serious tweaking, but (1) there is absolutely no valid reasons to have 2 separate lighttpd packages and (2) the 1.5 version is not stable enough. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpC2GyChKh9v.pgp Description: PGP signature
Re: RFS: pydict (Updated package)
On Thu, Jan 17, 2008 at 02:38:58AM +, Barry deFreese wrote: Dear mentors, I am looking for a sponsor for my package pydict. * Package name: pydict Version : 0.2.5.1-3.2 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : text It builds these binary packages: pydict - an English/Chinese Dictionary written with python/gtk The upload would fix these bugs: 405895 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pydict - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pydict/pydict_0.2.5.1-3.2.dsc FWIW (and sorry I don't have the time to look at it right now, I'll do if nobody did before next Wednesday) I believe the package should be orphaned, and packaging upgraded in the name of QA work. CHeers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpzDUNjaP43h.pgp Description: PGP signature
Re: lighttpd1.5
[EMAIL PROTECTED] On 1/17/08, Pierre Habouzit [EMAIL PROTECTED] wrote: On Thu, Jan 17, 2008 at 08:07:22PM +, Pierre Habouzit wrote: On Thu, Jan 17, 2008 at 07:23:40PM +, Ilya M. Slepnev wrote: Hi, I've packaged lighttpd1.5 package (svn r2048), closing this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=460433 and uploaded it to mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=lighttpd1.5 Can you look, if it is good packaged? Is it possible to upload it to Debian in experimental or unstable section? The reason, that I packaged it is that we need to use lighttpd1.5 in production, but Debian lighttpd maintainers build package only for 1.4version. Please just don't sponsor this upload. lighttpd is nowhere near production quality, and debian won't upload it. I don't know why I overlooked this bug report, it seems my procmail filter needs serious tweaking, but (1) there is absolutely no valid reasons to have 2 separate lighttpd packages and (2) the 1.5 version is not stable enough. Okay, I god confused with lighttpd 2.0, 1.5 is just the next in line in the same generation as 1.4.18 (currently in debian), and 1.5 is _NOT_ released yet. So packaging it is nonsense. I'm closing the bug, we don't package unreleased software, we only backport patches if needed. Even in experimental? Why are your talking about nonsense of packaging? It has sense. Can you really imagine a process of backporting modules from 1.5 to 1.4? I can cite lighttd.net: If you are developing a plugin for 1.4.x right now, be asured that it won't work without changes in 1.5.0. ( from here:http://blog.lighttpd.net/articles/2006/07/26/1-4-12-becomes-1-5-0 ) The question about quality of package is still actual. -- Thanks, Ilya M. Slepnev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lighttpd1.5
On Thu, Jan 17, 2008 at 09:51:45PM +, Ilya M. Slepnev wrote: [EMAIL PROTECTED] On 1/17/08, Pierre Habouzit [EMAIL PROTECTED] wrote: On Thu, Jan 17, 2008 at 08:07:22PM +, Pierre Habouzit wrote: Please just don't sponsor this upload. lighttpd is nowhere near production quality, and debian won't upload it. I don't know why I overlooked this bug report, it seems my procmail filter needs serious tweaking, but (1) there is absolutely no valid reasons to have 2 separate lighttpd packages and (2) the 1.5 version is not stable enough. Okay, I god confused with lighttpd 2.0, 1.5 is just the next in line in the same generation as 1.4.18 (currently in debian), and 1.5 is _NOT_ released yet. So packaging it is nonsense. I'm closing the bug, we don't package unreleased software, we only backport patches if needed. Even in experimental? One could package it in experimental indeed, though no-one will upload rogue packages like yours. If you are interested in maintaining lighttpd, please join the team, do not work behind its back. Why are your talking about nonsense of packaging? Beacuse it seems all but stable, and packaging unstable APIs or programs is a hell I'm not keen on trying. It has sense. Can you really imagine a process of backporting modules from 1.5 to 1.4? And by the greatest luck, there is no 1.5 modules in debian right now, so I believe we're safe for now. I can cite lighttd.net: If you are developing a plugin for 1.4.x right now, be asured that it won't work without changes in 1.5.0. Well, then develop it for 1.5.0 if you don't care about 1.4.x, so build yourself a development environment on your computer with the latest bleeding-edge svn snapshot, bless you. Be sure that lighttpd 1.5 will enter unstable as soon as it's released and of release quality. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp7YR5jZHmsA.pgp Description: PGP signature
SONAME vs illegal package name
Hi, I'm packaging OpenVAS and have the following problem. The upstream package for the component I am working on is called openvas-libraries, so I was initially going to package it as libopenvas. However, it contains two libraries, libopenvas and libopenvas_hg and I was getting complaints that libopenvas didn't match the SONAME (for libopenvas_hg.so), so I broke it down into one package per library (and a dev package for each) - libopenvas and libopenvas_hg. However I'm now getting complaints that the package name of libopenvas_hg is illegal. I am involved in the upstream project and as a last resort could rename the library although, obviously this may have a knock on for other developers and is therefore something I'd like to avoid unless necessary. Any suggestions about how to resolve this? If the solution is to patch the source to rename it, I'll probably patch it upstream. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SONAME vs illegal package name
On 17/01/2008, Tim Brown wrote: two libraries, libopenvas and libopenvas_hg and I was getting complaints that libopenvas didn't match the SONAME (for libopenvas_hg.so) FWIW, it is thought about removing this lintian check (I had a quick discussion with Russ Allbery in #459851[1]). 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=459851 so I broke it down into one package per library (and a dev package for each) - libopenvas and libopenvas_hg. However I'm now getting complaints that the package name of libopenvas_hg is illegal. It's not needed, especially if they are supposed to be updated altogether (unlike if they were libfoo and libar, with no relation at all between them). And indeed, you can't have any “_” in package name, see the Debian Policy 5.6.7. I'd suggest you let the lintian info/warning as it is for now, no need to override it AFAICT. Cheers, -- Cyril Brulebois pgpzSXC4lWtxb.pgp Description: PGP signature
Re: lighttpd1.5
[...] One could package it in experimental indeed, though no-one will upload rogue packages like yours. If you are interested in maintaining lighttpd, please join the team, do not work behind its back. Surely, i don't want to work behind your back! Please, calm down, I tried to contact lighttpd team, but your procmail filter needs serious tweaking, so I'm glad, that i contacted you at last. What do you mean, by calling a package rogue? Because of procmail filters or it is very bad-done? I'm debian maintaner for more then four years, so I wouldn't try to hijack a package or work behind your back and I respect your team and work, which you are doing for lighttpd and debian. Why are your talking about nonsense of packaging? Beacuse it seems all but stable, and packaging unstable APIs or programs is a hell I'm not keen on trying. It works stable for several clusters for us, BTW. It has sense. Can you really imagine a process of backporting modules from 1.5 to 1.4? And by the greatest luck, there is no 1.5 modules in debian right now, so I believe we're safe for now. Yes, that's the problem. Let's try that in experimental? [...] Well, then develop it for 1.5.0 if you don't care about 1.4.x, so build yourself a development environment on your computer with the latest bleeding-edge svn snapshot, bless you. Be sure that lighttpd 1.5 will enter unstable as soon as it's released and of release quality. OK, i understand, that it is impossible to enter for lighttpd 1.5 to enter unstable, surely. But what about experimental? I'm not a fanatic, for building bleeding-edge svn snapshot in a development environment, and i'm not trying to do your work. That's why I packaged 1.5 in separate package, for nobody to be confused about upgrade from 1.4 to 1.5. -- Ilya -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lighttpd1.5
[...] I'm debian maintaner for more then four years, so I wouldn't try to hijack a package or work behind your back and I respect your team and work, which you are doing for lighttpd and debian. Well I don't get why you seek sponsors outside from the team then. That's what I call rogue. In my world, when I ask for sponsoring of a package that has a responsive team, I call that hijacking. Sorry it took me 10 days to figure that my procmail was broken, you had bad luck, but I can't imagine how waiting only 7 (‽) days for hijacking a package is appropriate behaviour. If you read my first letter in this more carefully, there was no RFS:'s I was asking to help me with finding bugs, and I asked about ethical question, if it is good or bad to have two packages of lighttpd in distributive. I thought, that asking here will help me to contact with your team anyway) I was right. I didn't ask for sponsor! Let's try that in experimental? Like said _I_ won't do the job, but I don't see a problem with it being in unstable _IF_ done inside from the team. You're free to join it btw, but I'm not an alioth pkg-lighttpd admin, so you'll have to nag one of them, private mails would probably work easier. And if in those conditions, I'll gladly sponsor uploads. I'm glad, that we understand each other at last!-) BTW, can you have a look, at the package? Thanks, Ilya
Re: SONAME vs illegal package name
Tim Brown [EMAIL PROTECTED] writes: I'm packaging OpenVAS and have the following problem. The upstream package for the component I am working on is called openvas-libraries, so I was initially going to package it as libopenvas. However, it contains two libraries, libopenvas and libopenvas_hg and I was getting complaints that libopenvas didn't match the SONAME (for libopenvas_hg.so), so I broke it down into one package per library (and a dev package for each) - libopenvas and libopenvas_hg. However I'm now getting complaints that the package name of libopenvas_hg is illegal. The first question to ask is whether the two libraries will ever separately change SONAMEs. If the SONAME will always change in lockstep for both libraries, ignore lintian and just use a single library package. Multiple library packages are only useful if the libraries are going to change independently (and probably only useful if applications that link against the libraries may conceivably link to only one of them and not the other). I'm actually considering removing that lintian tag, since it's frequently the wrong thing to do. If the two libraries do change independently, you'll have to change the library package name to not include an underscore since underscore isn't allowed in package names in Debian. The recommendation (which will make lintian happy) is to replace _ with - in the package name. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lighttpd1.5
On Thu, Jan 17, 2008 at 10:34:41PM +, Ilya M. Slepnev wrote:
[...]
One could package it in experimental indeed, though no-one will upload
rogue packages like yours. If you are interested in maintaining
lighttpd, please join the team, do not work behind its back.
Surely, i don't want to work behind your back! Please, calm down, I
tried to contact lighttpd team, but your procmail filter needs
serious tweaking
Well, yeah, there was a matching bug in my procmailrc, that saw all my
alioth mail to into .debian.${MATCH}/ - .debian./ and oddly I wasn't
subscribed to this maildir. The procmail filter is now fixed.
I'm debian maintaner for more then four years, so I wouldn't try to
hijack a package or work behind your back and I respect your team and
work, which you are doing for lighttpd and debian.
Well I don't get why you seek sponsors outside from the team then.
That's what I call rogue. In my world, when I ask for sponsoring of a
package that has a responsive team, I call that hijacking. Sorry it took
me 10 days to figure that my procmail was broken, you had bad luck, but
I can't imagine how waiting only 7 (‽) days for hijacking a package is
appropriate behaviour.
Why are your talking about nonsense of packaging?
Beacuse it seems all but stable, and packaging unstable APIs or
programs is a hell I'm not keen on trying.
It works stable for several clusters for us, BTW.
I'm glad.
It has sense. Can you really imagine a process of backporting modules
from 1.5 to 1.4?
And by the greatest luck, there is no 1.5 modules in debian right now,
so I believe we're safe for now.
Yes, that's the problem.
I don't see how it can be a problem.
Let's try that in experimental?
Like said _I_ won't do the job, but I don't see a problem with it
being in unstable _IF_ done inside from the team. You're free to join it
btw, but I'm not an alioth pkg-lighttpd admin, so you'll have to nag one
of them, private mails would probably work easier. And if in those
conditions, I'll gladly sponsor uploads.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgp68Ei8PAKmF.pgp
Description: PGP signature
Re: ITR: varkon (updated package)
Erik Schanze [EMAIL PROTECTED] writes: IMO excluding of architectures is good if the program makes no sense on it, e.g. because of missing hardware. In your case it is a problem of unportable code, you should fix it before. Yes, generally I agree with you. But properly fixing the code certainly will take some time and I would like to get the package into sid before that, so people can start playing with it. I could file an RC bug myself to prevent it from migrating into testing and to let people know that it is going to be flaky on 64bit archs. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITR: varkon (updated package)
On Jan 18, 2008 8:08 AM, Matthias Julius [EMAIL PROTECTED] wrote: I could file an RC bug myself to prevent it from migrating into testing and to let people know that it is going to be flaky on 64bit archs. Better to run a test suite or otherwise cause an FTBFS on architectures where it is known to build broken or unusable binaries. Not being fully portable isn't an RC bug and will not block testing migration unless it is a regression and there is no good reason to block it from lenny if it only works on 32-bit arches. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
