Re: Patch problem -- always fuzzy?
Robert Bihlmeyer [EMAIL PROTECTED] writes: Interesting, I see the same behaviour. A diff generated with -u2 has no problems, OTOH. So you may want to work around this by manually replacing the chunk in the diff.gz with that. Won't that invalidate the md5 sums and make the package invalid? -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
Santiago Vila [EMAIL PROTECTED] writes: Robert Bihlmeyer wrote: (b) it's dubious whether another potato point release will be done at all. How can you be so certain about the dubiousness of that? :-) Where in my sentence is there any notion of certainity? We should consider *all* the possibilities, including (but not limited to) that the release of woody will be delayed and there will be more potato point releases. Sure that's possible, but in the light of a new release to work on, rather than updates to an old one, I don't think its probable. Doing a large backport that perhaps won't be used at all ... I wouldn't do that. Releasing a potato update that included the appropriate don't do that, then warning in the docs ... that's another thing. -- Robbe signature.ng
Re: g++ 3.0
Matt Zimmerman [EMAIL PROTECTED] writes: If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. Well, the package in question needs proprietary data to work. I'd have to upload this (large) data to a Debian machine -- a thing I'd rather avoid. Furthermore, some weeks ago, I asked here for a machine for developers with gcc 3.0 on it, and got no satisfactory answers. On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. Alpha is one problem child. AFAIK only mips* use 3.0 by default, currently. As long as it doesn't link against any other C++ libraries, it should work, yes. I bit the bullet and made the change for all archs. I can always downgrade single archs when bug reports accumulate. In that case, I'll also have at least one tester for that arch at hand. -- Robbe signature.ng
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
On Tue, 10 Jul 2001 15:57, Robert Bihlmeyer wrote: Matt Zimmerman [EMAIL PROTECTED] writes: The bug is not serious enough to justify an update to stable, especially not when we are preparing for a new release. You could of course upload a potato package anyway, and punt the decision to the release managers. AFAIK the package will end up in Adrian Bunk [EMAIL PROTECTED] runs a repository of packages back-ported to Potato (mainly for 2.4.x kernels and associated things). The repository is on http://www.fs.tum.de/~bunk/kernel-24.html . Why not ask to put your package on the same site? Or why not just put it on your own web page and tell anyone who asks about it (also tell one of the lists so that people who search the web can find it). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch problem -- always fuzzy?
Mikael Hedin [EMAIL PROTECTED] writes: Robert Bihlmeyer [EMAIL PROTECTED] writes: So you may want to work around this by manually replacing the chunk in the diff.gz with that. Won't that invalidate the md5 sums and make the package invalid? Yes, you need to fudge the sum in the .dsc (and .changes), too. Then, re-sign the package (debsign works fine for that). -- Robbe signature.ng
Re: g++ 3.0
Matt Zimmerman [EMAIL PROTECTED] writes: g++-3.0 is a big step, and when it becomes the default compiler, there will be a transition plan. Just build random packages with 3.0 is not a transition plan. I don't think we need a transition plan for packages not using C++ libraries. Some of these will surely not compile (the mips porters get hit by these bugs, anyway), but the others are IMO fair game. We do need a plan for C++ libraries and their dependees, that's for sure. Maybe conflicts are enought, maybe we need something like the glibc affair. Note that libqt3, a rather prominent example of a C++ library, already uses the g++ 3 ABI on Alpha (and maybe other random platforms, too). Every qt program that does not special-case alpha to g++ 3 is broken right now... Who's to say that building with g++-3.0 on i386 will not introduce new bugs? Nobody. But nobody guarantees that for gcc 2.95.17, either. So I wouldn't overly worry about that. Maintainers should be able to test their packages for such regressions. Since you can have multiple gcc versions on the same machine, these are easier to find out than arch bugs. -- Robbe signature.ng
Re: Policy question about web application
On Tue, Jul 10, 2001 at 12:43:37AM -0400, Matt Zimmerman wrote: I agree. I've had cricket's CGI scripts in a subdirectory since the beginning. Since they have generic names like 'grapher.cgi', it helps to show which package they belong to. IMO, any package which has more than one or two CGI scripts should do this (*cough*, doc-central). The one that really bugs me is viewcvs, which installs /usr/lib/cgi-bin/query.cgi. In fact, I think it deserves a wishlist bug. I also have a query.cgi in bugzilla that I had to rename. Ok I'm looking to make a proposal on policy. I think I'm a little to fresh Debian maintainer to do that but since there is no risk. This change may create some bugs againt http server while currently all package directly that install cgi under /usr/lib/cgi-lib work without change the server configuration, I'm not sure this be easy to for subdirectory. Rémi Perrot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Re: missing file in my package
Thank you for the information. I don't have time at the moment but i'm going to learn about DH_COMPAT 2 and 3, specially when DH_COMPAT 1 is deprecated. I promise that next time i build a package for esms, i'm going to use DH_COMPAT 2 or 3. Anyhow, the actual package i made works and i'd like it to be uploaded as soon as possible (lets see if it's in time to get into woody). Could you do the NMU? thanks, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/ On Mon, 9 Jul 2001 15:54:00 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: This is how you could track the problem (say you want to know more about DH_COMPAT) : [eric@femto:~]$ grep -r DH_COMPAT /usr/share/doc/* /usr/share/doc/debhelper/TODO:* DH_COMPAT 1. Can be removed once all packages are seen to be using 2 or /usr/share/doc/debhelper/examples/rules.indep:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules.multi2:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules.multi:export DH_COMPAT=3 /usr/share/doc/maint-guide/maint-guide.html/ch-dreq.html: 10 export DH_COMPAT=1 [eric@femto:~]$ - First line offers me to look at /usr/share/doc/debhelper/TODO : Deprecated: * DH_COMPAT 1. Can be removed once all packages are seen to be using 2 or higher. I won't hold my breath. - Next lines suggest that DH_COMPAT is strongly tied to debhelper, so [eric@femto:~]$ man debhelper [...] Debhelper compatability levels From time to time, major non-backwards-compatible changes need to be made to debhelper, to keep it clean and well- designed as needs change and its author gains more experi- ence. To prevent such major changes from breaking existing packages, the DH_COMPAT environment variable was intro- duced. DH_COMPAT may be set to a number, to determine which major revision of debhelper should be used. There are currently 3: V1 Setting DH_COMPAT=1 (or leaving it unset) causes deb- helper to act in compatability mode. It will use debian/tmp as the package tree directory for the first binary package listed in the control file, while using debian/package for all other packages listed in the control file. This mode is deprecated. [etc.] Please keep this thread Cc'd on [EMAIL PROTECTED] Other people would be interested in following it as well as there might be other people on the list who could answer your question too. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: wmmenu -- button bar dockapp
i'm (hopefully) starting the process of becoming a maintainer for wmmenufiled a wishlist bug on the package, and will need a sponsor to make sure i'm not too stupid in my packaging, upload the package, and maybe advocate for me if i've done an adequate job...(i think this is the process, but please correct me if i'm wrong)... anyway, i've already packaged the app, which is apt-get'able here: deb http://styro.dyndns.org/debian/ ./ deb-src http://styro.dyndns.org/debian/ ./ everything seems lintian clean and such, but all comments are welcome...application details below... tia, rob casson electronic information services librarian miami university oxford, oh -- Forwarded message -- Subject: ITP: wmmenu -- button bar dockapp Package: wnpp Severity: wishlist This is a dock application for Windowmaker, that provides a button bar to launch applications from. Downloaded from: http://www.fcoutant.freesurf.fr/wmmenu.html Copyright is GPL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch problem -- always fuzzy?
Robert Bihlmeyer [EMAIL PROTECTED] writes: Interesting, I see the same behaviour. A diff generated with -u2 has no problems, OTOH. So you may want to work around this by manually replacing the chunk in the diff.gz with that. Won't that invalidate the md5 sums and make the package invalid? -- Mikael Hedin, MSc +46 (0)980 79176 Swedish Institute of Space Physics +46 (0)8 344979 (home) Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile) [gpg key fingerprint = 387F A8DB DC2A 50E3 FE26 30C4 5793 29D3 C01B 2A22]
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
Santiago Vila [EMAIL PROTECTED] writes: Robert Bihlmeyer wrote: (b) it's dubious whether another potato point release will be done at all. How can you be so certain about the dubiousness of that? :-) Where in my sentence is there any notion of certainity? We should consider *all* the possibilities, including (but not limited to) that the release of woody will be delayed and there will be more potato point releases. Sure that's possible, but in the light of a new release to work on, rather than updates to an old one, I don't think its probable. Doing a large backport that perhaps won't be used at all ... I wouldn't do that. Releasing a potato update that included the appropriate don't do that, then warning in the docs ... that's another thing. -- Robbe signature.ng Description: PGP signature
Re: g++ 3.0
Matt Zimmerman [EMAIL PROTECTED] writes: If the problem occurs only on certain architectures, you may want to try it yourself on as many as possible before switching entirely to g++-3.0. Well, the package in question needs proprietary data to work. I'd have to upload this (large) data to a Debian machine -- a thing I'd rather avoid. Furthermore, some weeks ago, I asked here for a machine for developers with gcc 3.0 on it, and got no satisfactory answers. On some Debian architectures, 3.0 is already the default compiler (see the source for gcc-defaults, I think). If those are the same architectures where your package has problems, then there is no problem for Debian. Alpha is one problem child. AFAIK only mips* use 3.0 by default, currently. As long as it doesn't link against any other C++ libraries, it should work, yes. I bit the bullet and made the change for all archs. I can always downgrade single archs when bug reports accumulate. In that case, I'll also have at least one tester for that arch at hand. -- Robbe signature.ng Description: PGP signature
Re: [zeratul2@wanadoo.es: Bug#102811: grub: cannot access newer ext2 filesystems]
On Tue, 10 Jul 2001 15:57, Robert Bihlmeyer wrote: Matt Zimmerman [EMAIL PROTECTED] writes: The bug is not serious enough to justify an update to stable, especially not when we are preparing for a new release. You could of course upload a potato package anyway, and punt the decision to the release managers. AFAIK the package will end up in Adrian Bunk [EMAIL PROTECTED] runs a repository of packages back-ported to Potato (mainly for 2.4.x kernels and associated things). The repository is on http://www.fs.tum.de/~bunk/kernel-24.html . Why not ask to put your package on the same site? Or why not just put it on your own web page and tell anyone who asks about it (also tell one of the lists so that people who search the web can find it). -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: Patch problem -- always fuzzy?
Mikael Hedin [EMAIL PROTECTED] writes: Robert Bihlmeyer [EMAIL PROTECTED] writes: So you may want to work around this by manually replacing the chunk in the diff.gz with that. Won't that invalidate the md5 sums and make the package invalid? Yes, you need to fudge the sum in the .dsc (and .changes), too. Then, re-sign the package (debsign works fine for that). -- Robbe signature.ng Description: PGP signature
Re: g++ 3.0
Matt Zimmerman [EMAIL PROTECTED] writes: g++-3.0 is a big step, and when it becomes the default compiler, there will be a transition plan. Just build random packages with 3.0 is not a transition plan. I don't think we need a transition plan for packages not using C++ libraries. Some of these will surely not compile (the mips porters get hit by these bugs, anyway), but the others are IMO fair game. We do need a plan for C++ libraries and their dependees, that's for sure. Maybe conflicts are enought, maybe we need something like the glibc affair. Note that libqt3, a rather prominent example of a C++ library, already uses the g++ 3 ABI on Alpha (and maybe other random platforms, too). Every qt program that does not special-case alpha to g++ 3 is broken right now... Who's to say that building with g++-3.0 on i386 will not introduce new bugs? Nobody. But nobody guarantees that for gcc 2.95.17, either. So I wouldn't overly worry about that. Maintainers should be able to test their packages for such regressions. Since you can have multiple gcc versions on the same machine, these are easier to find out than arch bugs. -- Robbe signature.ng Description: PGP signature
Re: Policy question about web application
On Tue, Jul 10, 2001 at 12:43:37AM -0400, Matt Zimmerman wrote: I agree. I've had cricket's CGI scripts in a subdirectory since the beginning. Since they have generic names like 'grapher.cgi', it helps to show which package they belong to. IMO, any package which has more than one or two CGI scripts should do this (*cough*, doc-central). The one that really bugs me is viewcvs, which installs /usr/lib/cgi-bin/query.cgi. In fact, I think it deserves a wishlist bug. I also have a query.cgi in bugzilla that I had to rename. Ok I'm looking to make a proposal on policy. I think I'm a little to fresh Debian maintainer to do that but since there is no risk. This change may create some bugs againt http server while currently all package directly that install cgi under /usr/lib/cgi-lib work without change the server configuration, I'm not sure this be easy to for subdirectory. Rémi Perrot
Re: Re: Re: Re: missing file in my package
Thank you for the information. I don't have time at the moment but i'm going to learn about DH_COMPAT 2 and 3, specially when DH_COMPAT 1 is deprecated. I promise that next time i build a package for esms, i'm going to use DH_COMPAT 2 or 3. Anyhow, the actual package i made works and i'd like it to be uploaded as soon as possible (lets see if it's in time to get into woody). Could you do the NMU? thanks, -- Robert Millan Debian GNU (Hurd) user zeratul2 wanadoo es http://getyouriso.org/ On Mon, 9 Jul 2001 15:54:00 +0200, Eric Van Buggenhaut [EMAIL PROTECTED] wrote: This is how you could track the problem (say you want to know more about DH_COMPAT) : [EMAIL PROTECTED]:~]$ grep -r DH_COMPAT /usr/share/doc/* /usr/share/doc/debhelper/TODO:* DH_COMPAT 1. Can be removed once all packages are seen to be using 2 or /usr/share/doc/debhelper/examples/rules.indep:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules.multi2:export DH_COMPAT=3 /usr/share/doc/debhelper/examples/rules.multi:export DH_COMPAT=3 /usr/share/doc/maint-guide/maint-guide.html/ch-dreq.html: 10 export DH_COMPAT=1 [EMAIL PROTECTED]:~]$ - First line offers me to look at /usr/share/doc/debhelper/TODO : Deprecated: * DH_COMPAT 1. Can be removed once all packages are seen to be using 2 or higher. I won't hold my breath. - Next lines suggest that DH_COMPAT is strongly tied to debhelper, so [EMAIL PROTECTED]:~]$ man debhelper [...] Debhelper compatability levels From time to time, major non-backwards-compatible changes need to be made to debhelper, to keep it clean and well- designed as needs change and its author gains more experi- ence. To prevent such major changes from breaking existing packages, the DH_COMPAT environment variable was intro- duced. DH_COMPAT may be set to a number, to determine which major revision of debhelper should be used. There are currently 3: V1 Setting DH_COMPAT=1 (or leaving it unset) causes deb- helper to act in compatability mode. It will use debian/tmp as the package tree directory for the first binary package listed in the control file, while using debian/package for all other packages listed in the control file. This mode is deprecated. [etc.] Please keep this thread Cc'd on [EMAIL PROTECTED] Other people would be interested in following it as well as there might be other people on the list who could answer your question too. -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
ITP: wmmenu -- button bar dockapp
i'm (hopefully) starting the process of becoming a maintainer for wmmenufiled a wishlist bug on the package, and will need a sponsor to make sure i'm not too stupid in my packaging, upload the package, and maybe advocate for me if i've done an adequate job...(i think this is the process, but please correct me if i'm wrong)... anyway, i've already packaged the app, which is apt-get'able here: deb http://styro.dyndns.org/debian/ ./ deb-src http://styro.dyndns.org/debian/ ./ everything seems lintian clean and such, but all comments are welcome...application details below... tia, rob casson electronic information services librarian miami university oxford, oh -- Forwarded message -- Subject: ITP: wmmenu -- button bar dockapp Package: wnpp Severity: wishlist This is a dock application for Windowmaker, that provides a button bar to launch applications from. Downloaded from: http://www.fcoutant.freesurf.fr/wmmenu.html Copyright is GPL.
