Re: volunteer for orphaned package cantus, searching sponsor
On Fri, Jul 29, 2005 at 08:34:19PM +0200, Maximilian Mehnert wrote: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287985 > > Hello. > > I would like to volunteer to continue packaging cantus. > > Please feel free to contact me if you can spare the time to parent me. > > I will start working on this as soon as I have someone to talk to ;-) In Debian, it rather works the other way around -- the person interested in maintaining, should take the initiative, research how packaging works, make a new updated package, and find a sponsor for upload. See http://people.debian.org/~mpalmer/debian-mentors_FAQ.html If you really want to follow throught, don't forget to notify the bug report too, so the people can easily lookup the status. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Having a binary package in two source packages
On Sun, Aug 07, 2005 at 03:41:31PM +0200, Lo?c Minier wrote: > Hi, > > Is it possible to ship the same binary packages in two source packages > across two distributions? This situation can occur, but should be transitional and short. The archive will let the highest version numbered package supersede the old one, but then an upload of the other source package, will get rejected because there's already a newer version number. So, the superseded package's source package should be modified to no longer ship the obsolete binary package. > A concrete example would be a tools package which can be built from two > major upstream releases that need to be kept in the distribution for > the shared libs: > short term: > - unstable/testing: >* gstreamer0.8 source package: > - libgstreamer0.8 binary package > - gstreamer-tools > - experimental: >* gstreamer0.9 source package: > - libgstreamer0.9 binary package > - gstreamer-tools Different suites, no problem. > long term: > - unstable/testing: >* gstreamer0.8 source package: > - libgstreamer0.8 binary package >* gstreamer0.10 source package: > - libgstreamer0.10 binary package > - gstreamer-tools If gstreamer0.8 doesn't build gstreamer-tools anymore, that's ok. If it does, it's a bug, in a way release critical because it'd prevent security updates for gstreamer0.8 once testing becomes stable. In practice, it isn't that urgent to solve. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder -- chroot and build-dependencies.
On Thu, Sep 01, 2005 at 06:17:01PM +0300, Alexander A. Vlasov wrote: > Inside an unpacked source tree; > I call ~/bin/mydebuild, which is simple shell script: > #!/bin/sh > pdebuild --configfile ~/.pbuilderrc \ > --buildsourceroot fakeroot \ > --pbuilderroot sudo \ > $* > > I noticed this problem some time ago, but since it can be solved in most > cases by just installing one packages, I just ignored it. But now it > required ocaml... So instead, go up one dir, do "dpkg-source -b mldonkey-2.5.28" to build the .dsc without running clean, and then run "pbuilder mldonkey_2.5.28-2.dsc" --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building packages with epoch
On Sun, Dec 11, 2005 at 11:26:43AM +0100, Norbert Preining wrote: > Dear all! > > I have a question concerning packages with epoch: We are preparing a NMU > (maintainer approved) for tipa which currently is of version > 2:1.2-2 > When I get the source package via apt-get source tipa and rebuild the > package with > dpkg-buildpackage -us -uc -rfakeroot > I get a binary package called > tipa_1.2-2_all.deb > and not > tipa_2%3a1.2-2_all.deb If the epoch should've been in the .deb, it'd be ':', not '%3a' (which is the URL escaping of it, and this is the filename, not the URL). > But the internal version number (in the control file) of the package > is correct, as one can see when calling scanpackages I get a correct > entry: > Package: tipa > Version: 2:1.2-2 > > Any suggestions? What is the correct way to build packages with epoch? This is correct -- the epoch is *not* included in the filenames. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some files in /usr/share/doc/foo stay uncompressed, some are compressed
On Mon, Feb 13, 2006 at 05:16:21AM -0200, Nelson A. de Oliveira wrote: > Hi Marc! > > On 2/13/06, Marc Haber <[EMAIL PROTECTED]> wrote: > > > Please, don't treat me as a clueless newbie. The package in question > > is exim4-doc-html, the documentation for Debian's default MTA. The > > fact that I maintain that package should show that I have been around > > the block multiple times. > > Sorry for that. It wasn't my intention. > > Section 12.4 of Debian policy says that if we can provide > documentation in HTML, we should do this. As I understand, the txt > files are part of the html (there are links pointing to the txt, as > you said). If we want a fully functional HTML documentation, we need > the txt files uncompressed. > Section 12.4 is not clear about compressing files that are needed by > the HTMLs, but I would let it uncompressed. It's better in my opinion. > > Maybe include an explanation on README.Debian, saying why the files > are not compressed, but I don't know if it's necessary. I don't think users care about it, if it works. No note needed, it'd only confuse. > But in short, don't compress. It is better to end users. I agree here, it's the road of least confusion to the users. The space saved is probably pretty minimal anyway, considering the size of the total doc package already. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: has webmin disapeared on Etch/Sid?
On Sat, Feb 18, 2006 at 04:51:46PM -0200, Nelson A. de Oliveira wrote: > Hi! > > On 2/18/06, Rakotomandimby Mihamina > <[EMAIL PROTECTED]> wrote: > > On Sat, 2006-02-18 at 13:31 -0500, Kevin Mark wrote: > > [webmin & webmin-* package] > > > Any takers are welcome! even non-debian developers can do it! > > > > Ok, let's say I'll try to take it. > > - Where could I find the latest source package? I am _not_ going to > > rebuild the entire package. > > Here: > http://ftp.debian.org/debian/pool/main/w/webmin/ This is *not* the latest source package. The latest source was 1.230-1, and was removed in january (See #343897). The files in the above directory is the stable (sarge) version. I assume the last version is in the alioth subversion repository or so. Failing that, look at snapshot.debian.net Please note that a package like webmin is not easy to maintain, because it's quite involved and because of the nature of the beast (automatic configuration management, web interface) requires some intimate knowledge of Debian packaging. It might prove a very difficult task for an inexperienced maintainer, and I'd certainly not suggest such package as one to start with as Debian maintainer. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with the package tracking system commands?
On Sat, Feb 25, 2006 at 11:46:55AM -0500, Amadan Korvin wrote: > Hi I was wondering if someone on the mentors list woudl be willing to > help me with the PTS mailer commands? I am really having trouble but > could probably be sorted out with one or two examples... Please just ask your question, do not ask whether you may ask a question, that yields unnecessary turnarounds and noise on the lists. And as Justin noted, the [EMAIL PROTECTED] list is more suited for this question. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: b5
On Tue, Feb 28, 2006 at 07:55:35PM -0500, Justin Pryzby wrote: > On Tue, Feb 28, 2006 at 07:18:31PM +0200, Panu Kalliokoski wrote: > > On Wed, Mar 01, 2006 at 03:52:04AM +1100, skaller wrote: > > > > It's your call, but since making them non-native is not really that much > > > > more work, I'd recommend doing it that way. > > > However there is a reason, it is political, it is > > > relevant -- it convinced me anyhow :) I also initially > > > produced a native package. > > > > Thank you for this explanation. Although I still have some issues with > > it, it seems I should build infrastructure for building source packages. > > (Earlier, one just needed dpkg-source -b; now it seems there must be > > some script or makefile target to construct a fake .orig directory and > > then build the source with that.) It feels funny that I have to make a > > dummy "pristine" source for the Debian project while I've been releasing > > the "debian-specific" source outside Debian for ages. > The .orig *directory* is a temporary artifact created, used, and > removed by dh_make for initial packaging only; you don't need it. All > you need to have a nonnative package is to have a > ../$package_$version.orig.tar.gz. The problem is that it is often > misnamed. Actually, the .orig directory is a working dir for dpkg-source, and doesn't have so much to do with dh_make (it's just that dh_make uses dpkg-source too). For a non-native source package, you'll need an 'upstream' release and of course still your source tree with all packaging. You can use dpkg-source -su to create an orig source tarball. You'll then need to have both $pkg-$ver/ and $pkg-$ver.orig/ directories, the latter being the same as the former except for packaging files (typically, the debian/ directory). "dpkg-source -su $pkg-$ver $pkg-$ver.orig" will then create your source file. Basicly, you're actually working with two hats, one of the 'upstream' maintainer creating software for any linux distribution (and only including stuff relevant for that), and one of the package maintainer, including packaging stuff. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: diff.gz file missing
On Mon, Mar 13, 2006 at 10:43:30PM +0100, Rainer Dorsch wrote: > Which step/tool is supposed to generate a diff. I renamed the original > sources > to cpuinfo-0.4.1.orig.tar.gz before runing dpkg-buildpackage -rfakeroot Try cpuinfo_0.4.1.orig.tar.gz --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
(I'm not a Debian developer) On Mon, Dec 15, 2003 at 07:29:59PM +, Scott James Remnant wrote: > It's probably a good additional point that most of the standard > character sets have no ?? symbol and that there is no legal basis for > "(C)" being a valid representation of it. IANAL (but recently passed succesfully a computer science "Law and Computer Science" course), but 'legal basis'? I doubt that is needed for such a thing as the copyright sign, since under most countries' (including EU and US) copyright law, a work you authored is automatically 'copyright you'. Wether you simply write: "I wrote this", put the real or the `fake' (c) symbol in the file with your name, or even don't mention at all that the work is copyrighted by you (but for practical reasons, mentioning your name is useful). Google let me to [1], which does mention a benefit of using either the real copyright sign or the word 'Copyright' over the (C) representation (at least in the US): Copyright Law of the United States of America, item 401(d): Evidentiary Weight of Notice - If a notice of copyright in the form and position specified by this section appears on the published copy or copies to which a defendant in a copyright infringement suit had access, then no weight shall be given to such a defendant's interposition of a defense based on innocent infringement in mitigation of actual or statutory damages, except as provided in the last sentence of section 504(c)(2). Wether this whole section is applicable to software and its copyright-files is (for me) hard to tell since this section was written with tangible works in mind, rather than a mere series of bits and bytes. > On the other hand, policy states UTF-8 for Changelog which breaks katie > if your name contains accented characters because you're still forbidden > by policy to use UTF-8 in debian/control. Since UTF-8 isn't yet by default supported on all systems (at least not on my sarge system), I would rather choose for going on the safe side, using only 7-bit latin1. Because of [1], you should write 'Copyright' in full rather than (C) to be on the safe side in a legal sense. --Jeroen [1] http://www.copyright.gov/title17/92chap4.html -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl pgp9lV9lhDdyo.pgp Description: PGP signature
Bug#274832: Loading debconf module incorrectly detected for python
Package: lintian On Mon, Oct 04, 2004 at 12:06:04PM +0200, Brian Sutherland wrote: > When building the new schoolbell package I get a lintian warning: > > W: schoolbell-ssl: config-does-not-load-confmodule > N: > N: The config script must load one of the debconf libraries. > N: > > But, the first 2 lines of my config file are: > > #!/usr/bin/python2.3 > from debconf import * > > So I am thinking this is a lintian bug, or something wrong with the way > I import the library? > > Everything seems to work just fine. > > -- > Brian Sutherland -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Lintian warning bug?
On Mon, Oct 04, 2004 at 02:28:30PM +0200, Frank K?ster wrote: > Brian Sutherland <[EMAIL PROTECTED]> schrieb: > No, I think it is a bug to use python in the config script. Hm, good catch. Indeed. > Please read Policy 7.2. You would need a pre-depends on python, and I > doubt that this is a valid case for a pre-depends. Even pre-depends doesn't help, as the config script is run without ANY guarantee about available dependencies (debconf excluded), except essential stuff. Pre-Depends does work however for preinst, and indeed, this is most likely not a good reason for a pre-depends. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 10:26:13PM +0200, Geert Stappers wrote: > But I was looking for the hugh /usr/share so I tried > > lintian -C hus conglomerate_0.7.14-1_powerpc.deb > > Two snippets from the lintian manual page > >-C chk1,chk2,..., --check-part chk1,chk2,... > Run only the specified checks. You can either specify the name > of the check script or the abbreviation. For details, see the > CHECKS section below. > >huge-usr-share (hus) > Checks whether an architecture-dependent package does have a > significantly big /usr/share. Big amounts of architecture inde- > pendent data in architecture dependent packages waste space on > the mirrors. > > But still no sign of the hugh /usr/share > > > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > > note that due to its new, experimental nature, it is only displayed when > > you enable informative checks, by means of lintian -I. > > Hey a -I flag, lets try it: > > $ lintian -I conglomerate_0.7.14-1_powerpc.deb > I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% > > > Okay, I found what I was looking for > What is a constructive way to solve our different expections > of _all_ checks and "forceing hus check" versus the -I flag? This is indeed seemingly in conflict if you don't know how -C really interacts with lintian. -C is intended as a flag to _limit_ which checks are actually performed, i.e., how much CPU and I/O lintian spends on certain things. -I works at a higher level in lintian, it serves as to unhide certain warnings that are hidden by default. -I processing is done only _after_ all checks are performed, and -C is rather used for which checks are performed, and on its turn, doesn't know about -I... Anyway, I don't know really how to solve different expectations, as it _is_ kind of consistent now how those flags all cooperate. I think it'd better to make clear in documentation somehow that certain options are only useful if you're about to do some specialized large-scale package tests (-C), and emphasize those few options that _are_ relevant to everybody (IMHO, this is an exhaustive list of lintian options one should normally bother with: -I, -i, -o, --show-overrides, -m, --allow-root, -v, -V, -h, --print-version. All other options are maily for uses like the lintian invocation for lintian.debian.org). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Where to submit a bug?
On Fri, Oct 15, 2004 at 03:59:44PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: > Problem: as user of a random package X, I'd need to judge somehow if the > packager works well with upstream or not. The number of 'upstream' tagged > bugs, or untagged upstream bugs, or forwarded bugs etc. can give a hint, > but it's not clear. The real problem is those maintainers that don't work well with upstream. Rather than working around by sometimes submitting upstream, one should fix the root cause of the problem -- promote the communication and cooperation of Debian maintainers with their upstream. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Bugzilla package in need of help
On Wed, Oct 20, 2004 at 09:05:45AM +0200, Moritz Muehlenhoff wrote:
> In linux.debian.devel, you wrote:
> > It came to my attention that the 'bugzilla' Debian package is currently
> > not in Sarge, due to several RC bugs.
> >
> > If you consider this package worthy of inclusion in Sarge (note that is
> > is in woody, so not shipping it in Sarge would be a regression, and
> > leaving users of the Debian bugzilla package in the cold), please lend a
> > hand. More than 1% of the popcon users actively use bugzilla at the
> > moment.
>
> I once made a package of 2.16.6 for internal use that fixes four of the
> five release-critical bugs (26077{2,3,4}, 250638). 253841 isn't "serious"
> IMO; it's not as convenient as it could be, but if 1% of all popcon users
> use it actively it cannot be _that_ seriously broken. Bugzilla is a
> complex package after all.
> The 2.16.6 packages can be grabbed from http://www.tzi.de/~jmm/debian/
Thank you for your work.
Since Moritz isn't a DD, anyone willing to NMU based on his work?
I checked the interdiff, and
- I did not verify that the new .orig.tar.gz is indeed genuine
- it should use NMU-type version numbering, and mention it's an NMU
- the new copyright file should be fixed to do have a newline at the end,
otherwise it looks okay
- the following duplicates the call to fix_www_data_perm for
/var/cache/bugzilla, and in addition, this change should be mentioned in the
changelog referring to a bugreport (I now cannot check the validitiy of this
change since I don't see why this is changed)
--- bugzilla-2.16.5/debian/bugzilla.postinst
+++ bugzilla-2.16.6/debian/bugzilla.postinst
@@ -68,7 +68,9 @@
fix_www_data_perm('/var/lib/bugzilla'); #this should be done by checksetup.pl
fix_www_data_perm('/var/cache/bugzilla'); #but I dislike the way this is done.
-
+fix_www_data_perm('/var/cache/bugzilla'); #but I dislike the way this is done.
+system(qq{chmod -R a+x /usr/lib/cgi-bin/bugzilla}) == 0
+ or die "Can't fix owner of CGI-BINs";
exit 0;
Otherwise, it looks okay to me, though I didn't test the package at all.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: compilers that self compile
On Wed, Oct 20, 2004 at 01:18:39PM -0300, Antonio S. de A. Terceiro wrote: > Hello all, > > How do people in Debian handle compilers that depend on itself to > be compiled? I asked this question a while ago too. Quoting DWN[1]: | Cyclic Build Dependencies. Jeroen van Wolffelaar [11]noticed that | [12]oaklisp contains a binary file which is used for bootstrapping. | There are at least half a dozen such [13]loops in Debian already. | Edmund Grimley Evans [14]assumed that such cyclic build dependencies | are acceptable in Debian. | | 11. http://lists.debian.org/debian-legal/2004/06/msg00113.html | 12. http://packages.debian.org/oaklisp | 13. http://lists.debian.org/debian-legal/2004/06/msg00116.html | 14. http://lists.debian.org/debian-legal/2004/06/msg00114.html So, yes, that's acceptable[2]. You must ensure you can change sources as you like, and then get a new package, but you don't need to make bootstrapping possible/easy. >* can a package build-depend on itself? I've saw that gcc, for > example, don't (at least explicitily) build-depend on itself. It does in a way: build-essential is an assumed build-dependency, and gcc is depended on by build-essential. ghc6 does build-depend on itself. >* how packages like those go in the repository for the first time? By ignoring build-depends while in some way you've made your system to actually be able to build the package. I.e., you've for example bootstrapped the compiler. Then you install it locally, and build your package again, this time the normal way, and you upload it. After it's in the archive, it's rebuildable by itself. > I couldn't find references about that on either in Debian Policy Manual > or in Debian Developer's Reference. If I missed something, please point > me were. This is indeed something which IMHO needs to be clarified. --Jeroen [1] http://www.debian.org/News/weekly/2004/24/ [2] Technically, this very issue was not a cyclic build-depends at package level, but there was some 'binary in source package' hack involved -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: compilers that self compile
On Thu, Oct 21, 2004 at 02:33:35PM -0300, Antonio S. de A. Terceiro wrote: > My idea is to make a first release with sources already translated > (which can be done with a precompiled binary for i386 distributed by > upstream), which would compile fine with just g++ and libxml2-dev as > build-dependencies. Then, when/if it goes into repository, it will be > possible to compile a second release from untranslated sources, since > ac++ itself will be already available. I'd not suggest to do so, because you're then having a pre-translated source in as source package, something that would be non-trivial to just modify and then work with changes -- a requirement for Debian main. > I've requested that upstream distribute one version already translated. > .orig.tar.gz has to be officially distributed by upstream to be > considered pristine, hasn't it? It isn't a requirement that the .orig.tar.gz is identical to upstream, but anyway, you can always add stuff in the diff if you want. However, in this case I wouldn't go that route. I suggest to locally on your own system do whatever you need to do to get a ac++ package (and indeed document this carefully in the rules file). If the translations are architecture independent, and available on some upstream website, that'd make it easy for porters. Then, you can build-depend on your self, and make sure you have a ac++ source package that can build itself from pristine .orig.tar.gz without any help (just requiring the ac++ being installed already). If this succeeds, you can upload this ac++ package, once it's in unstable, it can also be build in unstable, using itself. Note: I'm not a porter. > Will this approach make manual porting unnecessary? Possibly, but while you include such hand-crafted translations somewhere in the source package, I doubt it's satisfying all of the DFSG guidelines. You could of course still do so, and file a RC bug on your own package while you have this hack in place, so to easy porting indeed... But that'd be quite hacky, and I'm quite unsure whether such a tactic would be appreciated. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
RFS: nload -- A realtime terminal network usage monitor
Hi,
In response[0] to Martin Michlmayr's request[1] for temporarily
maintainers, I've prepared an updated nload[2] package.
We would want to sponsor this package? Chances are, one more upload will
be forthcoming for cosmetic changes (standards-compliance) and possibly
a build-fix (see forwarded mail for more information), and that's it
until new upstream version comes.
The diff is really small, especially compared to current unstable
version. If you decide to sponsor, please do read the second of the
issues I've noted in the below-forwarded message.
Description: A realtime network usage monitor.
Nload is a console application which monitors network traffic and bandwidth
usage in real time. It displays the total amount of data that has been
transfered over a network device since the last reboot, the current bandwidth
usage, and the minimum, maximum, and average bandwidth usage measured
since it started.
If the user wants, it is also able to display two bars, similar to progress
bars, presenting the current load graphically. Support for displaying several
devices simultaneously is included.
Changes:
nload (0.6.0-1) unstable; urgency=low
* Temporary new maintainer: Jeroen van Wolffelaar
* New upstream version
* Compile fixes in NMU were already fixed in new upstream (Closes: #141920)
* Remove debian manpage, upstreams has one now (partially fixes #222170)
* Fix debian/rules to execute upstream's `make install' properly
* config.{sub,guess} updated (from now on automatically) (Closes: #114994)
-- Jeroen van Wolffelaar <[EMAIL PROTECTED]> Mon, 12 Jan 2004 13:48:53 +0100
See the below-forwarded mail for more information.
[0] <[EMAIL PROTECTED]> (sorry, archives down, so
no http link); forwarded below
[1] <[EMAIL PROTECTED]>
[2] http://jeroen.a-eskwadraat.nl/sw/debian/nload-temp.tar
----- Forwarded message from Jeroen van Wolffelaar <[EMAIL PROTECTED]> -
Date: Mon, 12 Jan 2004 14:34:47 +0100
To: debian-devel@lists.debian.org
Subject: Re: Temp maintainers wanted: fspanel, nload, openverse
From: Jeroen van Wolffelaar <[EMAIL PROTECTED]>
Resent-From: debian-devel@lists.debian.org
On Mon, Jan 12, 2004 at 10:58:14AM +, Martin Michlmayr wrote:
> I'm looking for temporary maintainers (i.e. people who actually use
> this software, but who're willing to give the package back when the
> maintainer returns) for fspanel, nload and openverse. Package
> descriptions are below.
>
> Package: nload
> Description: A realtime network usage monitor.
I use this occasionally, it is an extremely simple package.
Anyway, new upstream release + bugfixes to the debian/rules files
available from http://jeroen.a-eskwadraat.nl/sw/debian/nload-temp.tar
(Lintian clean, fixes largest part of all one bug, the remaining things
in that bug are wishlist)
Changes:
nload (0.6.0-1) unstable; urgency=low
* Temporary new maintainer: Jeroen van Wolffelaar
* New upstream version
* Compile fixes in NMU were already fixed in new upstream (Closes: #141920)
* Remove debian manpage, upstreams has one now (partially fixes #222170)
* Fix debian/rules to execute upstream's `make install' properly
* config.{sub,guess} updated (from now on automatically) (Closes: #114994)
-- Jeroen van Wolffelaar <[EMAIL PROTECTED]> Mon, 12 Jan 2004 13:48:53 +0100
Three issues:
- I'd need a sponsor for this since I'm no DD (only in NM queue)
- Couldn't confirm for sure #141920 was indeed fixed upstream,
since I have no access to an unstable hppa. Either someone should
check it, or I'll re-apply the NMU's patch if the hppa buildd fails on
it.
- Segfaults when /proc not available, since this is a rather non-issue
usually, unless you compile & test from chroot, because it's no security
risk. I'll bugreport to upstream directly.
--Jeroen
--
Jeroen van Wolffelaar
+31-30-253 4499
[EMAIL PROTECTED]
http://Jeroen.A-Eskwadraat.nl
- End forwarded message -
--
Jeroen van Wolffelaar
+31-30-253 4499
[EMAIL PROTECTED]
http://Jeroen.A-Eskwadraat.nl
pgplfbuykpIBd.pgp
Description: PGP signature
Re: data files in /etc?
On Fri, Feb 13, 2004 at 07:25:42PM +0100, Bernhard R. Link wrote: > * Magos?nyi ?rp?d <[EMAIL PROTECTED]> [040212 22:52]: > > -if one wants to make the boot process unable to modify configuration, > > they will also be stumbled upon. (And given the fact that mount > > actually deletes and recreates /etc/mtab, the challenge is... > > challenging.) > > At least some time ago mount was able to deal with /etc/mtab > beeing a link to /proc/mounts. (As long as no loop-devices It breaks usrquota --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: How to adopt Debian packages
On Tue, Feb 24, 2004 at 07:40:10PM +0100, Alexander Schunk wrote: > Hallo, > > ich m?chte gerne folgende Debian pakete, die zur > Adoption frei sind, ?bernehmen. > [I want to take over the following Debian packages that are up for > adoption] First, this list is an English list, so please write English so that all subscribers can read what you mean. Please understand that maintaining a package means taking responsability and a commitment to keep maintaining these packages. Therefore, you're expected to get familiar with Debian packaging. > -dhelp > -Kernel-Patch > -pppoeconfig > -auto-gpg > > Ich hab bereits die ehemaligen Maintainer kontaktiert > und mir die Quellen runtergeladen. Good. If you really want to take them over, please state your intentions in the corresonding bugs, like http://bugs.debian.org/210439 This way, other people can see that. > Mein Problem ist nun, wie ich die Pakete mit meinem > Namen wieder hochladen kann. If you have read these three documents: http://www.debian.org/doc/maint-guide/ http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/developers-reference/ You can find instructions here on how to ask help: http://www.debian.org/doc/maint-guide/ch-helpme And, that list, debian-mentors@lists.debian.org, is indeed the list to ask for sponsors to get your package looked at, you getting feedback about it, and eventually, some Debian developer can upload it for you. Alternatively, you can also consider providing a NMU (Non-Maintainer upload) for those packages, to fix the Release Critical bugs. They get you with somewhat less responsibility for that package: you're not expected to maintain the package in that case. The easiest you can do, is simply submit a patch to the correct bug (by mailing [EMAIL PROTECTED]), you can do that without any privileges or authorization from others, and it is highly appreciated. > Ich benutze T-online ?ber Windows als Browser. Most Debian work is not being done with a browser, but with email and ftp. You do need a Debian system if you want to maintain or fix a Debian package of course! I don't really understand what you mean with this line. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: lintian's warning
On Sat, Mar 06, 2004 at 01:15:45PM +0100, Bartosz Fenski aka fEnIo wrote: > Hello. > > I'm packaging makeself[1] for Debian (#200151). > I've got the followoing errors/warnings: > > ([EMAIL PROTECTED])~/nowy$lintian makeself_2.1.2-1_i386.changes > E: makeself: binary-without-manpage makeself > W: makeself: executable-not-elf-or-script ./usr/lib/makeself/makeself-header > ([EMAIL PROTECTED])~/nowy$ > > The first one isn't a problem for me (I'll write this manpage). > But what about second one? Makeself comes with some additional script > which doesn't comply to Debian's policy. > > It starts with: > cat << EOF > "$archname" > #!/bin/sh > # This script was generated using Makeself $MS_VERSION > > What should I do with that? > Is it a suitable situation to use lintian's override feature? It shouldn't go in /usr/lib anyway, as this file is NOT architecture-dependent: it's the same whether you install it for i386 or sparc or whatever. It should go to /usr/share instead. I don't know the purpose of this script, but without a #!-line, it will not always run fine, as people can have anything as shell, and certainly some shells won't understand that 'cat << EOF > "$archname"' line. If it is not intended to run directly from a shell, but rather used as input like: 'sh /usr/lib/makeself/makeself-header', or sourced from within as '/bin/sh' script, it should not be executable. Hope this helps, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp0GZGDpzK1q.pgp Description: PGP signature
Re: How to access cvs.debian.org with ssh/rsa keys?
On Sat, Mar 06, 2004 at 05:51:49PM +0100, Frank K?ster wrote: > Hi all, > > I've recently been given write access to the tetex directories on > cvs.debian.org, but it seems when I login, the password is blown over > the net in plaintext. > > I have put my rsa key into the LDAP system, and can login e.g. into > gluck with ssh. Since the key is protected by a password, I'm asked this > password, but then the question asked is: > > Enter passphrase for key '/home/frank/.ssh/id_rsa': > > I have set CVS_RSH=ssh, and I try to access the cvs with > > cvs -d :pserver:[EMAIL PROTECTED]:/cvs/tetex login > Logging in to :pserver:[EMAIL PROTECTED]:2401/cvs/tetex > CVS password: > > This doesn't look like ssh authentication. What am I doing wrong (or > what should I have read)? I don't know about cvs.debian.org, but 'pserver' is the CVS protocol, you want to use 'ext'. cvs -d :ext:[EMAIL PROTECTED]/cvs/tetex co test does try a ssh connect (I cannot login), so that seems to solve it (maybe you do need a different port though). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: debian-changelog-file-uses-obsolete-national-charset
On Tue, Mar 30, 2004 at 11:24:30AM +0200, Andreas Metzler wrote: [...] > > If you change debian/changelog to UTF-8 you have to also change > debian/control, otherwise the maintainer-ids won't match and your > upload will be classifed as NMU. Another possibility (because it won't make the maintainer UTF-8, with all kind of troubles thereof) is to make sure the 'Changed-By' (in .changes) is _not_ UTF-8. By default, it's taken from the most recent signature in the changelog, but that can be overridden. No script other than the dpkg-genchanges script will really look into the changelog, so it's possible to contain UTF8 usage withing the changelog only. This is the -e option to dpkg-genchanges, which can also be given (and will then passed on) to dpkg-buildpackage, and if you use debuild, you can no doubt also give that option to debuild (but didn't check my last assumption). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Why Katie thinks it's an NMU?
On Thu, Apr 01, 2004 at 05:09:09AM +0200, Goswin von Brederlow wrote: > Andreas Barth <[EMAIL PROTECTED]> writes: > > > The version number has no effect at all whether katie considers > > something to be a NMU or not. > > > > > > Cheers, > > Andi > > Something in the archive scripts does care. Binary only NMUs are > recognised by having a tree part debian version (1.2-3.4.5) instead of > the normal one part (maintainer upload) or two part (source NMU). If > nothing would care a rebuild would be triggered on all archs not > uploaded. Err, why should katie do that based on the version number? That's very unlikely, katie can simply see whether the .changes file contains a source too, even more, katie doesn't care about buildd's, (iirc) quinn-diff does, and because of the nature of the upload (no new source attached), everything goes magically alright because there _is_ nothing to rebuild? Version numbering w.r.t. (Binary/Source) NMU's is a convention thing, mandated by policy. The archive scripts do not care other than for version ordering. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Why Katie thinks it's an NMU?
On Thu, Apr 01, 2004 at 03:54:49PM +0100, Colin Watson wrote: > On Thu, Apr 01, 2004 at 08:38:54AM +0200, Jeroen van Wolffelaar wrote: > > Version numbering w.r.t. (Binary/Source) NMU's is a convention thing, > > mandated by policy. The archive scripts do not care other than for > > version ordering. > > They do care a little bit, actually. There's a check for every > binary-only upload whether there's corresponding source in the archive. > For binary-only NMUs as opposed to normal porting uploads, they need to > know how to fiddle the version number to look for the source, so -1.0.1 > becomes -1 and -1.1.1 becomes -1.1. In a .dsc, there is a 'Source:' entry (only if source pkg != bin pkg, and/or source versionnr != bin versionnr), which points to the source. So no need to fiddle with the version number, which would be really tricky. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Why Katie thinks it's an NMU?
On Fri, Apr 02, 2004 at 01:29:31AM +0200, Goswin von Brederlow wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > In a .dsc, there is a 'Source:' entry (only if source pkg != bin pkg, > > and/or source versionnr != bin versionnr), which points to the source. > > So no need to fiddle with the version number, which would be really > > tricky. > > > > --Jeroen > > How does that help if you upload "foobar 1.2-3.4.5" without any > source? No dsc file to check. *sigh*, obviously, I meant .deb here. For example, cpp_3.3.3-2_i386.deb contains the header: Source: gcc-defaults (1.14) Any .deb indicates its source, including binary-only NMU's, so no version number fiddling is needed to find the source (which would be impossible too, is 1.2-0.0.1 a binary NMU of 1.2, or of 1.2-0? Though nonstandard, the latter isn't forbidden) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Why Katie thinks it's an NMU?
On Thu, Apr 01, 2004 at 11:30:54PM +0200, Goswin von Brederlow wrote: > Jeroen van Wolffelaar <[EMAIL PROTECTED]> writes: > > > On Thu, Apr 01, 2004 at 05:09:09AM +0200, Goswin von Brederlow wrote: > > > Andreas Barth <[EMAIL PROTECTED]> writes: > > > > > > > The version number has no effect at all whether katie considers > > > > something to be a NMU or not. > > > > > > > > > > > > Cheers, > > > > Andi > > > > > > Something in the archive scripts does care. Binary only NMUs are > > > recognised by having a tree part debian version (1.2-3.4.5) instead of > > > the normal one part (maintainer upload) or two part (source NMU). If > > > nothing would care a rebuild would be triggered on all archs not > > > uploaded. > > > > Err, why should katie do that based on the version number? That's very > > unlikely, katie can simply see whether the .changes file contains a > > source too, even more, katie doesn't care about buildd's, (iirc) > > Only the initial upload contains a source, the buildd uploads and > manual port builds don't. > > Katie ensures that the initial upload does in fact contain > source, or rather it checks if source for an upload are > available. Sources for a binary only recompile upload (1.2-3.4.5) > have to look for the non recompile version for source (1.2-3.4 > diff/dsc, 1.2 orig.tar.gz or 1.2-3.4 tar.gz). I never said otherwise. As you quoted myself: > > Err, why should katie do that based on the version number? ^^^ And indeed, if you read katie (and jennifer), you will find it doesn't care, it uses afaics the 'Source:' header from the .changes. > > quinn-diff does, and because of the nature of the upload (no new source > > attached), everything goes magically alright because there _is_ nothing > > to rebuild? > > > > Version numbering w.r.t. (Binary/Source) NMU's is a convention thing, > > mandated by policy. The archive scripts do not care other than for > > version ordering. > > They do, see above. This doesn't follow at all from above, your logic is flawed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Binary-only uploads cause dangling 'Source:' reference in .deb's (Was: Re: Why Katie thinks it's an NMU?)
(moved to d-d) On Fri, Apr 02, 2004 at 12:28:32PM +0100, Colin Watson wrote: > On Fri, Apr 02, 2004 at 11:53:43AM +0200, Jeroen van Wolffelaar wrote: > > Any .deb indicates its source, including binary-only NMU's, > > I'm afraid you're wrong there; I have some binNMUed packages here and > they do *not* indicate the source version. > > $ dpkg -I liboo2c_1.5.9-3.0.1_powerpc.deb | grep Source >Source: oo2c > > I know of no non-heuristic way to find the exact source version > associated with a binary-only NMU. That is because the source _was_ changed for this binary only NMU: (from the changelog:) oo2c (1.5.9-3.0.1) unstable; urgency=low * Binary-only NMU for powerpc. * Really build for libgc1, not libgc6c102. -- Colin Watson <[EMAIL PROTECTED]> Thu, 6 Nov 2003 12:18:19 + And, the version at the first line of the changelog, is the source version. So, the dpkg-genchanges and dpkg-buildpackage scripts take that version as source version, and by uploading the thus produced binary without this changed (!) source, you get a binary without corresponding source. Because of the heuristics in katie (indeed, I missed that, I looked at various check_source functions and such), this upload was still accepted, don't know why [I don't know the _reason_, I do know why it's accepted technically] (the change in katie was committed end july 2003 by ajt, with comment: kelly, lisa, jennifer: update to use the new source_exists). IMHO, this is a suboptimal solution. In theory, with source header you can always track the source. However, because currently binary-only NMU's which don't follow this property are accepted by katie, this isn't always true. I see two possibilities to fix this, as this is a useful property to have (and gets rid of heuristics): - A binary upload is to be performed indeed binary-only, that is, no changes to the source beforehand (thus, also no change to the changelog). To build a binary NMU this way, one needs to override the .deb version at dpkg-gencontrol time. Can be done by a hack in 'rules' (hack, because this _is_ a source change...), or making some kind of interface to that, so that dpkg-gencontrol sets version of 1.2-1.0.1 if for example environment orders it to do so (enviroment var is set by dpkg-buildpackage in respond to some command-line option). Problem: rebuild isn't documented in changelog Problem: dpkg-gencontrol isn't mandatory. Other solution: a tool to change the version of a .deb after it's created, by modifying the Version: and Source: fields correctly. - The changelog IS updated, but the source version is still taken as the original one. Unless you want to hand-edit the .deb's, dpkg-buildpackage will then need to be changed such that correctly understands this (i.e., you need to override what the source version is, it cannot be taken from changelog), and thus makes a correct Source: header in the .deb's. Binary NMU's are then not strictly binary-only (you cannot rebuild it from source, you'll then lose the updated changelog). However, this is current practice, and I think the changelog is a good candidate to be the only exception to the 'binary-only' rule, for obvious reasons. I'm a bit indifferent about whether or not changelog updates for binary NMU's are okay, because of its nature, there is no source-change, and one could argue a changelog entry is unneeded, while OTOH, the binary .deb obviously _did_ change. > > so no version number fiddling is needed to find the source (which > > would be impossible too, is 1.2-0.0.1 a binary NMU of 1.2, or of > > 1.2-0? Though nonstandard, the latter isn't forbidden) > > katie tries both of those possibilities. Which is IMHO a bit of a hack (because: heuristics), and also one cannot rely on the Source: header then: I consider this a bit strange, Debian mandates sources for every binary package, but at the same time, binary-only uploads are accepted with a dangling reference to the source package. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Binary-only uploads cause dangling 'Source:' reference in .deb's (Was: Re: Why Katie thinks it's an NMU?)
On Fri, Apr 02, 2004 at 04:35:13PM +0100, Colin Watson wrote: > On Fri, Apr 02, 2004 at 04:29:54PM +0200, Jeroen van Wolffelaar wrote: > > On Fri, Apr 02, 2004 at 12:28:32PM +0100, Colin Watson wrote: > > > On Fri, Apr 02, 2004 at 11:53:43AM +0200, Jeroen van Wolffelaar wrote: > > > > Any .deb indicates its source, including binary-only NMU's, > > > > > > I'm afraid you're wrong there; I have some binNMUed packages here and > > > they do *not* indicate the source version. > > > > > > $ dpkg -I liboo2c_1.5.9-3.0.1_powerpc.deb | grep Source > > >Source: oo2c > > > > > > I know of no non-heuristic way to find the exact source version > > > associated with a binary-only NMU. > > > > That is because the source _was_ changed for this binary only NMU: > > > > (from the changelog:) > > > > oo2c (1.5.9-3.0.1) unstable; urgency=low > > > > * Binary-only NMU for powerpc. > > * Really build for libgc1, not libgc6c102. > > > > -- Colin Watson <[EMAIL PROTECTED]> Thu, 6 Nov 2003 12:18:19 + > > > > And, the version at the first line of the changelog, is the source > > version. So, the dpkg-genchanges and dpkg-buildpackage scripts take that > > version as source version, and by uploading the thus produced binary > > without this changed (!) source, you get a binary without corresponding > > source. > > I don't know if you realize this, but *all* binary-only NMUs currently > are performed this way. This is nothing remotely new, and I didn't do > anything non-standard. The point is that new source isn't uploaded, and > the changelog entry is considered sufficiently minor not to worry about. I do realize that, sorry if I wasn't clear. I didn't want & didn't mean to say this particular oo2c case was wrong, I was rather trying to get clear (also for myself) why this was failing. Anthony Towns already pointed out in this thread the (very old...) bug[1] in the BTS against dpkg to fix this issue, filed by himself about 4 years ago. I failed to find that bug when googling for it. About everything I said in my mail was already said by Anthony Towns in his bugreport. Including the two possible approaches to solve it (change changelog and make that work alright, or don't change changelog, and have a real just-recompile, even the method (env vars) is in it...). What I didn't say, and Antony Towns did, is "So, could something to this effect be applied to dpkg soonish, please?" (to no effect to-the-moment). Pro the non-changelog thing is, that one can order a buildd to recompile with correct version number, while currently manual changelog editing is needed. > You really do have to update the changelog, IMHO; if nothing else > something somewhere needs to say why you're making the binNMU. In the .changes, dpkg-buildpackage --rebuild=n would force you to also supply a text for 'Changes:'? I don't really think it needs to be in the changelog, as it was merely a fix for a botched build. Anyway, IMHO whichever way is chosen doesn't matter much, I think the most important thing is that either is implemented. There are currently less than 94 binary NMU's in the archive across all archs. It deals with about 10 source packages I think, plus quite some on s390 (which has by far the most binary NMU's). I think it's achievable, if this dpkg bug is fixed, to have sarge without dangling Source: references. --Jeroen [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=62529 PS: kernel-patch-2.4.x-mips (which is Arch: all?) has versions like 2.4.22-0.030928.5, which seems a bit wierd to me. How is one supposed to NMU or bin-NMU _that_? -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Separating packages.
On Tue, Apr 06, 2004 at 08:18:55AM -0400, Erik Bourget wrote: > Fabian Fagerholm <[EMAIL PROTECTED]> writes: > > > > > Thanks! (to you and everyone who pitched in). d-m is really friendly. Because Fabian wrote: > This is perhaps the most difficult thing to understand about Debian > packaging. It's implied in several places, and it's briefly spelt out in > some other places, but in general, you are referred to "examples" which > vary as much as the packages in the Debian archive. Maybe it's an idea to improve the available documents? (thinking NM guide) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: DD packages overview vs bugs
On Fri, Apr 23, 2004 at 07:59:10PM +0200, GCS wrote: > Hi, > > I have just noticed, that on the summary page of my packages[1] the > already closed bugs still shown in xmms-blursk. On the PTS page I can > see that the bugs are closed, and will be archived in 26 days. Is it > normal, ie why I can't see the same with cvs2svn, where I also have > closed bugs going to be archived, but not showing up at the summary > page? The bugs on developer.php is broken due to merkel being restricted, and on the PTS it's broken too due to some configuration change... Only the BTS has the correct info at the moment. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 12:03:42PM +0200, Jeremy Lain? wrote: > instance using dh_movefiles (see manpage) if you use debhelper. dh_movefiles is deprecated, use dh_install instead. It has options to keep track of install'd stuff, so that it can warn you if you forget to install some files in any package. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 01:55:59PM +0200, Geert Stappers wrote: > * put the the debian directory online. That makes it easier to check. > ( twice a wget, an untar, an unzip and appling and patch >could be avoid (by you) for your peer reviewers ) You can better use dpkg-source -x on the dsc: extra -x, but it unpacks correctly if: - the basename inside the .orig.tar.gz is different - the diff has a diffent basename - it makes debian/rules executable and, not in the least: it's the preferred, 'offical' way te extract a source package, and you can run lintian on the .dsc too. Comments on the package itself: - Copyright is inadequate, you _need_ to copy the full copyright statement in debian/copyright: > Copyright: > > It's available on the GPL. - This package lacks a copyright statement at all, it is undistributable - Section for the -dev should be libdevel, not devel. See http://packages.debian.org/unstable/ - Are you sure this is optional, and not extra? See http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections - After I debuild'd it, I noticed a new directory libinklevel-0.6.2 inside my libinklevel-0.6.2 directory, something is wrong - This is probably not okay: | cd /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib && rm -fr libinklevel.so && \ | ln -s libinklevel.so.2.0.6.2 libinklevel.so | ldconfig /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib | ldconfig: Can't create temporary cache file /etc/ld.so.cache~: | Permission denied | make[1]: *** [install] Fout 1 I don't know much about library building, but the debian build process should not touch the environment, that includes it should not run ldconfig. Did you read all associated documentation? The NM guide in full, the Packaging Manual in full? You really _need_ to have read them, and yes, it is much text. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 03:21:01PM +0100, Colin Watson wrote: > On Sat, May 01, 2004 at 03:04:50PM +0200, Jeroen van Wolffelaar wrote: > > - This is probably not okay: > > > > | cd /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib && rm -fr libinklevel.so > > && \ > > | ln -s libinklevel.so.2.0.6.2 libinklevel.so > > | ldconfig /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib > > | ldconfig: Can't create temporary cache file /etc/ld.so.cache~: > > | Permission denied > > | make[1]: *** [install] Fout 1 > > > > I don't know much about library building, but the debian build process > > should not touch the environment, that includes it should not run > > ldconfig. > > And what's it doing messing about in /tmp? That's because I debuilded in /tmp, it uses correctly $(CURDIR) in the makefile :) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFS: for two orphaned packages
On Mon, May 10, 2004 at 04:15:23PM +0200, Andreas Metzler wrote:
> On Mon, May 10, 2004 at 03:07:50PM +0200, Bartosz Fenski aka fEnIo wrote:
> > On Mon, May 10, 2004 at 02:38:37PM +0200, Andreas Metzler wrote:
> > > > Ok now I changed dependencies to xlibmesa-gl-dev, xlibmesa-glu-dev.
> > >
> > > > And I made changes to rules file so now I'm using:
> > >
> > > > -find images -name *.ppm.gz -print0 | xargs -0r rm -f
> > > > -find images -name *.pbm.gz -print0 | xargs -0r rm -f
> > >
> > > > Hope this solves every issue talked on list.
> > >
> > > Too easy. ;-) The wildcard (*.ppm.gz) needs to be quoted, otherwise
> > > the shell will (try to) expand it before find sees it.
> > >
> > > -find images -name '*.ppm.gz'
> >
> > Ok. Done already ;)
>
> Well, I find something new everytime I try. ;-)
>
> cp debian/config.{guess,sub} .
> cp: cannot stat `debian/config.{guess,sub}': No such file or directory
> make: *** [build-stamp] Error 1
>
> "cp debian/config.{guess,sub} ." only works with bash. Use
> "cp debian/config.guess debian/config.sub ."
Also, better depend on autotools-dev, and copy them from
/usr/share/misc/.
That way, they are always uptodate.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > Hi all, > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge There is, today. Notice that xfree86 itself was also stalled by it... Expect your package to go in tomorrow. Do not simply change the architecture field because one or two architectures are behind, rather, try to research *why* your package doesn't go to testing. In this case, Bjorn's page shows wrong information (Cc'ing him). It said: Adding xfree86-driver-synaptics makes 1 non-depending packages uninstallable on s390: xfree86-driver-synaptics But xfree86-driver-synaptics wasn't in testing to begin with (at least, afaics). Exact reason I don't understand (Sarge's X did have s390), but it doesn't matter anymore. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I personally disagree: - it's an ugly workaround - it's hiding problems (s390 failures) - there is no good reason to not support s390, so your removal request might even be rejected (I don't know of course what would really happen, I cannot speak for ftp-master of course). - it adds extra workload to ftp-master, which is unnecessary - it means two extra unnessesary uploads, causing extra load on the buildd's, again, quite unneeded --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... > > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: Oops, I was wrong... I checked out the xfree86 source package, but not the xserver-xfree86 binary package of it. Indeed, it is not available on s390, and never will, since s390 is a mainframe without input controls. Also, s390 doesn't have any possibility to connect a touchpad to. I don't really know what to do about it, maybe ask d-d (this is a quite tricky problem) or debian-release. Some suggestions I heard: - contact ftp-master to add this one to Packages-arch-specific - make your package FTBFS on s390, and have ftp-master remove the s390 binary. It will propagate nicely then, a FTBFS on an unsupported architecture is possible. But this will make s390 attempt to build it, so isn't really nice to do. So the best thing you can do is ask ftp-master for advice I think. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, May 11, 2004 at 01:52:55PM +0300, Juuso T?hk?p?? wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? I got from the .changes: Maintainer: Juuso T??hk??p <[EMAIL PROTECTED]> Changed-By: Juuso Thkp <[EMAIL PROTECTED]> which is the cause. You should write your name in debian/control at 'Maintainer:' in UTF-8 too for the Debian archive scripts to recognise this is the same person (and thus recognise it as a maintainer upload, rather than a Non-Maintainer Upload aka NMU). Historically, only plain ASCII (that is excluding the a with ) is allowed in debian/control, but if you're going to violate that (unwritten) rule (which is quite common and an understandable wish) you should use UTF-8. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Upload of a new package
On Wed, May 19, 2004 at 08:59:32AM +0200, Fabio Tranchitella wrote: > Hi, >I'm the mantainer of phpldapadmin, a web-based tool for managing ldap > servers. I'm not (yet!) an official Debian developer, so I asked for a > sponsor. He checked my package and uploaded in the unstable debian > archive about ten days ago... > > Here my questions: > - how long takes the verification process and when will be the package > available in unstable? How can I monitor the state of the package? Whenever somebody of the ftp-master team checks your package, and does the necessary paperwork on it. Usually one to two weeks, but it can be slightly longer. > - A new minor upstream version is available for the package, my sponsor > told me it is better to wait the package enters in unstable before > send the new version, because every upload before this happens "reset > the timer" and I have to wait more time to see my package in unstable. That is only true for unstable -> testing progress, this is _not_ true for NEW processing (what this is). So you can have this uploaded right away, and the newest of the two will apprear in unstable. I don't know exactly, but it might be that there is a potential problem closing bugs with the first upload (both are progressed to unstable simultaneously, and if the older one is refused because the newer one happens to get there first, it's bugs aren't closed). I'm not sure though whether this issue exists. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpC78k3g4yTm.pgp Description: PGP signature
Re: setgid-wrapper
On Wed, May 19, 2004 at 07:53:46AM -0400, James Damour wrote: > On Tue, 2004-05-18 at 09:03, Steven Augart wrote: > > As you probably know, when a shell sees that it is running a setuid or > > setgid shell script, it detects this because the euid and ruid or egid > > and rgid are different. It "fixes" this by setting the euid to be the > > same as the ruid, and/or egid the same as the rgid, effectively > > turning off the setuid/setgid bit. Huh? This is wrong. It is the kernel who refuses to set the UID or GID on execution of setuid/gid shell scripts. Where did you read that? > Actually, I didn't know that. Thanks for the info! Well, it's false. The shell doesn't do anything special with it. > > But, if the egid and rgid are the same, then the shell script leaves > > them alone. (Indeed, unless it's running as root, it has to leave > > them alone -- it does not have permission to do anything else.) The shell never does anything with them. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpDni7XHqxip.pgp Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Sat, Dec 21, 2002 at 08:04:05PM +0100, Xavier Antoviaque wrote:
> Hello,
>
> I try to use the convention proposed by Rob Bradford a few weeks ago.
>
> Package name: leo
> Version : 3.10
> License : Python licence
> Upstream Author : Edward K. Ream <[EMAIL PROTECTED]>
> Upstream URL: http://personalpages.tds.net/~edream/front.html
> Package URL : http://foobbs.org/debian
> NM status : first package (no application yet)
> GPG key ID : 75DC 9C3D 5537 8694 A57F 1423 2FB4 F9FF 2AD1 9DF6
> Description : a literate editor with outlines for X-Window
Some remarks, not that I'm not a Debian Developer (yet), but before leo can be
included in Debian, these issues need to be resolved anyway
- The .diff.gz is huge, because you included a number of html files
ripped from a website. Please don't do that this way. You didn't note
the source of the html pages in the debian/copyright file, it's not
sure whether you were allowed to do so (I fail to see a license about
it anywhere, and without license to redistribute those .html files,
it's illegal to do so). You should ask upstream to include
documentation in the package itself.
If you do want to include extra html files, I'd suggest -- if it's
allowed and such -- to either make a separate source package for the
leo-docs package, or include it in the .orig.tar.gz (in the latter
case, you'll need to include in the .orig.tar.gz both the original
.zip file and the .html files, and unpack the zip in your debian/rules
file).
- Not your fault (see date of original message), but a new upstream is
available
- If you include your own manpage (great that you've written one -- did
you sent it upstream already?), as sgml. You included the generated
manpage in the .diff.gz: don't do that, have build it into
debian/, leo.1 is a generated file.
- debian/rules: don't invoke programs with /usr/bin/, but
simply (docbook-to-man)
- You fail to build-depend on debhelper and python
- In debian/control, use ${python:Depends}, in stead of hardcoding the
python dependencies
- I don't think it's priority 'optional', see
http://www.debian.org/doc/debian-policy/ch-archive#s-priorities
- Description: Capitalize it correctly, and don't start it with 'a', but
something like 'Literate editor ...'
- Remove the dh-make generated example postinst.ex et al
- debian/changelog: 'This is my first Debian package' -- Is that
relevant for this very package?
- debian/copyright: it has huge lines, you could reformat them to fit 78
chars
- leo(1): It's /usr/share/doc/, not /usr/doc (was already the case in
2002)
- Is it really necessary to have both .GIF and .ico and .bmp's in
/usr/share/leo/Icons? Also, the 'Thumbs.db' file seems to me as an
artifect of a certain Operating System, and shouldn't be installed in
/usr/share
- When running leo just after installing, I get this:
[EMAIL PROTECTED]:~$ leo
Traceback (most recent call last):
File "/usr/share/leo/leo.py", line 190, in ?
shutil.copyfile('/etc/leo/leoConfig.leo', os.path.join(deb_user_conf_path,
'/leoConfig.leo'))
File "/usr/lib/python2.3/shutil.py", line 38, in copyfile
fdst = open(dst, 'wb')
IOError: [Errno 13] Permission denied: '/leoConfig.leo'
Which indicates to me leo is trying to write to the root filesystem.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
pgpbONn4LfjSm.pgp
Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Mon, May 24, 2004 at 10:08:51PM +0200, Jeroen van Wolffelaar wrote: > On Sat, Dec 21, 2002 at 08:04:05PM +0100, Xavier Antoviaque wrote: > > Hello, > > > > I try to use the convention proposed by Rob Bradford a few weeks ago. > > > > Package name: leo > > Version : 3.10 > > License : Python licence > > Upstream Author : Edward K. Ream <[EMAIL PROTECTED]> > > Upstream URL: http://personalpages.tds.net/~edream/front.html > > Package URL : http://foobbs.org/debian > > NM status : first package (no application yet) > > GPG key ID : 75DC 9C3D 5537 8694 A57F 1423 2FB4 F9FF 2AD1 9DF6 > > Description : a literate editor with outlines for X-Window > > Some remarks, not that I'm not a Debian Developer (yet), but before leo can be > included in Debian, these issues need to be resolved anyway (...) Also, upon installation you should somehow create precompiled python files (*.pyc). I don't know python myself, but there must be some preferred way to do so, iirc there is a (unofficial?) python policy. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp3wZW3Wopou.pgp Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Tue, May 25, 2004 at 12:24:16AM +0200, Xavier Antoviaque wrote:
> On Mon, 24 May 2004 22:08:51 +0200
> Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
>
> > Some remarks, not that I'm not a Debian Developer (yet), but before
> > leo can be included in Debian, these issues need to be resolved anyway
>
> Thanks for your reply, its helps a lot.
You're welcome.
> I repackaged leo, I hope it solves the problems you are pointing out.
I'm doing only a very shallow check now (time to go to bed really :)
> You will find it in http://foobbs.org/debian/leo/
>
> > - The .diff.gz is huge, because you included a number of html files
> > ripped from a website. Please don't do that this way.
>
> I ripped it off. The contents of this documentation are in the
> LeoDocs.leo, anyway.
k.
> > - Not your fault (see date of original message), but a new upstream is
> > available
>
> Fixed.
>
> > - If you include your own manpage (great that you've written one --
> > did you sent it upstream already?), as sgml. You included the
> > generated manpage in the .diff.gz: don't do that, have build it into
> > debian/, leo.1 is a generated file.
>
> Fixed. I also switched to XML DocBook.
>
> As for sending the man-page upstream, I will make a bundle with some
> patches to fix hard-coded paths I needed to change by hand.
ok.
> > - debian/rules: don't invoke programs with /usr/bin/, but
> > simply (docbook-to-man)
>
> Fixed - but this time with xsltproc.
>
> > - You fail to build-depend on debhelper and python
>
> Fixed for debhelper, and for Python there is no build-depend, at least
> in the current package.
building the previous package failed on my system, dh_python seemed to
require python to run. Indeed, dh_python(1) says so.
Since you're still using dh_python, you _do_ need to builddepend on
python. Alternatively, you could also drop dh_python, if you're sure you
don't need anything special.
I don't know python to be honest, so I don't know why dh_python doesn't
generate the .pyc generation code, and whether or not that is bad or
good.
> > - In debian/control, use ${python:Depends}, in stead of hardcoding the
> > python dependencies
>
> I tried to use it, but it gives bad results : it does not detects the
> need for python-tk, and requires python2.3, even if python2.2 can be
> used.
python2.3 seems to be default on Debian Sarge, and python is rumoured to
be broken w.r.t. backwards compatibility and such. Why not drop
python2.2? (Since I'm a python-know-nothing, you might want to ignore my
question :) )
> > - I don't think it's priority 'optional', see
> > http://www.debian.org/doc/debian-policy/ch-archive#s-priorities
>
> I do not see any other category that could fit. Could you be more
> specific ?
I mean, I think it's 'extra', rather than 'optional'. Sorry I was so
cryptic.
According to the quoted URL, 'optional' is for stuff you might
reasonably want by default on a system, I don't think leo fits in that
category (admittingly, quite some optional stuff doesn't fit it very
well, so feel free to ignore this if you think it's really appropriate
to be 'optional'.)
> > - Description: Capitalize it correctly, and don't start it with 'a',
> > but something like 'Literate editor ...'
>
> Fixed. That policy was modified since 2002, isn't it ? I remember being
> careful about this point.
Eh, don't know by heart... Anyway, it's just how the majority of
descriptions are, and if everybody would follow the majority, it'd
become consistent, which is a good think :).
(...)
All cool.
> > Also, upon installation you should somehow create precompiled python
> > files (*.pyc). I don't know python myself, but there must be some
> > preferred way to do so, iirc there is a (unofficial?) python policy.
>
> Yes : there even are autogenerated postinst and prerm scripts by
> debhelper for this. But as Leo has to work with both python2.2 and
> python2.3, I do not see a correct way to handle the generation of .pyc
> for both versions (except packaging two versions of Leo).
This is food for debian-python@lists.debian.org, I really have no clue.
Good work by the way, it seems that you've quite quickly fixed some
details on the package now :).
Since this is a python package, you maybe have better luck asking over
there for a sponsor too, by the way (after you've asked your 2.2 <-> 2.3
question).
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > Hello, > > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? The proper way is to simply not upload to mentors.d.n with 'official' debian revision numbers. Assuming the offical version will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by one, append a mentor-specific part). This way, there is never a clash, you can see from the version number it's an unoffical version. Two alternative approaches: - simply increment debian revision, and use -v appropriately, it doesn't matter certain debian-revisions are never uploaded. Disadvantage: changelog cluttering, usually people won't have those unofficial intermediate versions, and the differences among those are not very interesting usually. If you merge the topmost changelog entry every time, you seemingly have gaps in version numbering according to changelog, not very nice either. - Don't care about m.d.n, simply have your fixed version uploaded with the same version number. m.d.n is unoffical anyway, you in no way have to take care of proper upgrade paths at all. Disadvantage: in bugreports with reportbug, and for the user itself, it's hard to see whether the user/reporter has an unoffical version, or the official one. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Fri, Jun 04, 2004 at 04:26:05AM +0200, Remco Seesink wrote: > The manpage of dput doesn't help me with that. Any suggestions how to get > firebird_1.0.3.orig.tar.gz uploaded? -sa on dpkg-buildpackage (or debuild) See dpkg-buildpackage(1) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: why are these packages in testing?
On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote: > Hi, > > I came across some strange outputs. For example: > > [EMAIL PROTECTED]:~$ madison aiksaurus > aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source > aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, > hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > > There is a current removal suggestion by vorlon: > # 20040509 > # bug #241279 > remove aiksaurus/1.0.1+cvs.2004.02.20-1 > > Why is there only the source in testing? Because 7 out of 9 binary packages of that source are still in testing: http://lintian.wolffelaar.nl/histmadison/?source=aiksaurus&package=&date=2004-06-07 Note that the testing output says removal fails due to buggyness of the package: http://packages.qa.debian.org/a/aiksaurus.html # Trying to remove package, not update it # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) # Not considered I guess the textual representation is bogus, otherwise removals can't really have worked before. > Similar, for libapache-mod-filter, there is: > [EMAIL PROTECTED]:~$ madison libapache-mod-filter > libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > but there is also a removal suggestion, and the excuses-file on > ftp-master says according to > http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter > that this package is removed today from testing. So, why is this still > there? How many hours after the generation of the excuses list are the > packages really updated? 'today' means 'just before next mirror pulse', i.e., it will be gone after tonight. Testing scripts run just after a mirror pulse, and have effect only upon next one, so there generally is a delay of about 20 hours iirc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Tue, Jun 08, 2004 at 11:58:26AM +0200, Geert Stappers wrote: > On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote: > > But if the NMU is a new upstream version 1.2, then the correct NMU > > version is 1.2-0.1. This is in the Debian Developer's Reference: > > > > "If it is absolutely necessary for someone other than the usual main- > > tainer to make a release based on a new upstream version then the person > > making the release should start with the debian-revision value `0.1'." > > > > -- DDR 5.11.4.1: Source NMU version numbering > > Okay, that reads like: > If there is no offical Debian maintainer yet, then use -0.1. Policy only discusses verion number rules for uploaded versions, it doesn't discuss version numbers for private use. Use common sense for that, for example, either of the three possibilities I posted earlier (with advantages/disadvanteges even). > Also there is no harm in that it looks a like a NMU, It is confusing, but since it's unofficial, you'll only hurt yourself and your beta-testers. > it _says_ there is no one in Debian maintaining the package. No, this is plainly wrong, the version number an sich doesn't say anything about whether or not somebody in Debian is maintaining the package. Only the Maintainer: field of the latest package in sid days so, possibly with hints to future changes in wnpp. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: UTF-8 changelog?
On Sat, Jun 12, 2004 at 12:02:46AM +0200, Magos?nyi ?rp?d wrote: > Hi! > > Lintian tells me that there are obsolete national charset characters > in debian/changelog, and I have to convert it to UTF-8. > > The national characters are in my name. First I have converted > changelog, then lintian figured out that I do an NMU. So I also > converted control. > > Now I cannot debsign, because I could not properly tell gnupg my name > in UTF-8 encoding (cut&paste did not actually work). > > How did you handle the situation? > (I convert back to latin-2 for the time being, but I am overly > interested in the Right Way.) Use the -e'Your Name <[EMAIL PROTECTED]>' to dpkg-buildpackage, in ASCII (you need to have write your name without any non-ASCII, that is, non-7bit, characters). If you want to write your name in non-7bit characters, you'll need to do so in UTF-8, there is no real policy yet for this issue, but the consensus seems to be it becomes '_if_ you use non-7bit characters, those must be in UTF-8'. So in the latter case, write your name in debian/control in UTF-8 too. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: UTF-8 changelog?
On Fri, Jun 11, 2004 at 11:36:14PM +, Magos?nyi ?rp?d wrote: > A levelez?m azt hiszi, hogy Jeroen van Wolffelaar a k?vetkez?eket ?rta: > > > changelog, then lintian figured out that I do an NMU. So I also > > > converted control. > > > Use the -e'Your Name <[EMAIL PROTECTED]>' to dpkg-buildpackage, in > > ASCII (you need to have write your name without any non-ASCII, that is, > > non-7bit, characters). > > > So in the latter case, write your name in debian/control in UTF-8 too. > > It is already done. Now I have to tell gnupg my name in UTF-8. But how? Use the -k flag of dpkg-buildpackage, see dpkg-buildpackage(1) for details. See debuild(1) if you use that, you can have several of these flags hardcoded there (at least your Key ID, since on your account, that won't change ever). You'll also need it anyway when you're sponsoring. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: How to use reportbug from inside a chroot?
On Tue, Jul 06, 2004 at 10:50:13AM +0200, Frank K?ster wrote: > Andreas Metzler <[EMAIL PROTECTED]> schrieb: > > > On 2004-07-05 Frank K?ster <[EMAIL PROTECTED]> wrote: > >> while I use woody+backports on my working machine, I keep an up-to-date > >> sid chroot for developping purposes. When reporting a bug I find in the > >> chroot, I have to save it in a file and then rerun reportbug on woody, > >> because I do not have an MTA installed in the chroot. > > [...] > > > > reportbug --smtphost=localhost > > cu andreas > > And this works with exim (woody's exim) installed on localhost, without > an smtp server? No, but you could teach exim to also listen and relay mail incoming from 127.0.0.1:25, just as if it were incoming from /usr/sbin/sendmail. Note that ssmtp also works by relaying mail onwards via SMTP. Since you're in a chroot, you'll _need_ to use some kind of network socket to get mail out of the chroot -- having your MTA listen locally on 25 and use ssmtp is the staightforward way to do so. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
RFS: phpbb2 (security RC bug, one-time sponsorship of existing package)
Due to holiday of usualy sponsor, could somebody sponsor http://wolffelaar.nl/~jeroen/phpbb.tar for me? Fixes grave security bug, tested okay, no real changes to package except the new upstream sources of course. Thanks, --Jeroen -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Jul 2004 23:30:39 +0200 Source: phpbb2 Binary: phpbb2-languages phpbb2-conf-mysql phpbb2 Architecture: source all Version: 2.0.10-1 Distribution: unstable Urgency: high Maintainer: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Changed-By: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Description: phpbb2 - A fully featured and skinneable flat (non-threaded) webforum phpbb2-conf-mysql - Automatic configurator for phpbb2 on MySQL database phpbb2-languages - phpBB2 additional languages Closes: 258705 259298 260015 Changes: phpbb2 (2.0.10-1) unstable; urgency=high . * New upstream security release (Closes: #259298, #260015) * Fixed debconf typo, and added Japanese debconf translation, thanks to Hideki Yamane (Closes: #258705) Files: bc07e790346584aeade16748dbd1e03b 639 web optional phpbb2_2.0.10-1.dsc 491304f74504a23293eb1f3bb74c9905 3291318 web optional phpbb2_2.0.10.orig.tar.gz d3e259b75562873d2792e6b50b1c140b 26521 web optional phpbb2_2.0.10-1.diff.gz 396de494f64bbe407a4c5dca0b1da44f 488932 web optional phpbb2_2.0.10-1_all.deb 34b2254ef56b47c26cb56e895781d4cb 32360 web optional phpbb2-conf-mysql_2.0.10-1_all.deb 05d025395a00c398462d2e84dbb2ef5a 2788512 web optional phpbb2-languages_2.0.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCC63l2uISwgTVp8RAjM9AJ9Y6Ft6JLle1oRS6ufh3P1vY3L/0QCggzWr vHgp9CAbUrJwR+Y+fCkHoc0= =alAW -END PGP SIGNATURE- -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: How to retire a bug tagged wontfix,woody?
On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: > Then downgrade it. There's a mismatch there anyway. A serious bug > should *never* be tagged as wontfix. Either it needs to be fixed or > it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. RC bugs tagged woody (and not sarge or sid) do in no way affect sarge's release, you can safely leave them around for documentation purposes (i.e., letting people know you're aware of the bug in woody, but that it won't be resolved in woody, so people won't file new bugs for it). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > Hi all, > > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? Your package in sid/sarge needs to confirm to the latest policy version, whatever you put in standards-version. That field is only a reminder to yourself, of what policy version you checked your package. Nothing automatic happens with it, you can technically set it to anything without any practical effect. 3.6.1 has compared to 3.6.0 only a deprecation, with a 'should' (i.e., not 'must'), so you can safely put 3.6.1 and not lying. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
[jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
This is debian-mentors stuff, IMHO. Sorry, I don't have time myself to answer this now, this list probably will. --Jeroen - Forwarded message from James Damour <[EMAIL PROTECTED]> - Subject: Re: Please help sorting out which sid updates need to make sarge From: James Damour <[EMAIL PROTECTED]> Reply-To: "James Damour (Suvarov454)" <[EMAIL PROTECTED]> To: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Date: Sun, 15 Aug 2004 11:15:01 -0400 I apologize if you did not intend to have maintainers email you directly, but you didn't specify any other communication mechanism (except waiting for an email next week... I'm trying to be helpful and proactive). I recently adopted the orphaned package named "filler" and uploaded a new version to Sid that hasn't made it into Sarge because it FTBFS. Mind you, the old (orphaned) version **also** FTBFS, so I'm not really sure how it made it into Woody; perhaps it got grandfathered in when the Debian policy on Java was changed. Nevertheless, I wanted to let you know that there is only bugs that the Sid version closes are the "package orphaned" bug and a complaint about the documentation. I don't know if either bug is considered important for the Sarge release, and I don't know the policy on replacing one FTBFS version of a package for another. Perhaps the package should be dropped from Sarge? On Sat, 2004-08-14 at 19:29, Jeroen van Wolffelaar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Executive summary: If you maintain one or more packages that are > out-of-sync in sarge, please go to http://www.wolffelaar.nl/~sarge/, > read the guidelines, login, lookup your own packages, and fill in the > questions. > > Full story: > > We are currently quite close to the release of the next Debian version, > Sarge. Dozens of packages are uploaded to sid daily, and it looks like > by far not all of them are going to make it into sarge. > > Currently, there are about 1500 packages that have a different version > in sid than they have in sarge. Bugs are closed when they are fixed in > sid, bugs aren't reported very often if they are only present in sarge, > and not in sid, and sid simply still has more users than sarge. > > This situation has a high risk of letting important bugs slip into the > sarge release, and that is not good. Trying to track bugs that were > fixed in sid but not yet in sarge is very tedious, and also not all bugs > and issues are reported in the BTS. > > A better approach to this issue is to judge manually on all those > package that are out-of-sync whether the sid version contains essential > fixes that really ought to make it into Sarge. For this purpose, I > hereby call on all maintainers that have packages that are out-of-sync, > to let the release team know whether this is the case. 1500 packages is > too much for a few volonteers, since it requires intimite insight on all > the changes made in the package between the sarge and the sid version. > > Please visit http://www.wolffelaar.nl/~sarge/ , the site where this is > administred. Next week the maintainers of those packages of which it is > still unknown whether the sid version contains important fixes will be > asked by mail to provide their judgement. > > Thank you for your cooperation, > - --Jeroen > > - -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] > http://jeroen.A-Eskwadraat.nl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFBHpsqKN6ufymYLloRAga9AJ0YVRRavXOwe2kLJB3zyZLy1P9AEQCffH2z > L+UoodIklLlEXAdEJBLh6Po= > =xetU > -END PGP SIGNATURE- -- James Damour (Suvarov454) <[EMAIL PROTECTED]> - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpXfMaCmz6el.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > It was my understanding from the Debian Java policy > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > by depending upon the java2-runtime (which is *not* supplied by gcj > 3.3), the filler package is correctly identifying a dependency that > wasn't satisfied on the system of the user in bug 255831. The fact that > there is *NO* package in Debian (main or contrib) that satisfies the > dependency is what causes the FTBFS bug. On the other hand, once the > Free Java hackers catch up, filler should run without modification. filler is in contrib, see http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib packages in contrib are allowed to FTBFS due to missing dependencies in Debian. You may close any FTBFS bugs on filler caused by missing java2 packages in Debian referring to the debian policy, it is acceptable for contrib to FTBFS due to missing dependencies. Your package doesn't propagate to testing at the moment due to missing depends, but this issue is currently being worked on by Andreas Barth. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp1LKOwvWueC.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, Aug 15, 2004 at 06:03:40PM -0400, James Damour wrote: > On Sun, 2004-08-15 at 17:31, Jeroen van Wolffelaar wrote: > > On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > > > It was my understanding from the Debian Java policy > > > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > > > by depending upon the java2-runtime (which is *not* supplied by gcj > > > 3.3), the filler package is correctly identifying a dependency that > > > wasn't satisfied on the system of the user in bug 255831. The fact that > > > there is *NO* package in Debian (main or contrib) that satisfies the > > > dependency is what causes the FTBFS bug. On the other hand, once the > > > Free Java hackers catch up, filler should run without modification. > > > > filler is in contrib, see > > http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib > > > > packages in contrib are allowed to FTBFS due to missing dependencies in > > Debian. You may close any FTBFS bugs on filler caused by missing java2 > > packages in Debian referring to the debian policy, it is acceptable > > for contrib to FTBFS due to missing dependencies. > > OK, good to know. It's in packaging policy, one of the few must reads for maintainers... (others are DFSG, developers-reference, and preferable new-maintainers guide too). > > Your package doesn't propagate to testing at the moment due to missing > > depends, but this issue is currently being worked on by Andreas Barth. > > > I didn't know that. Should I try to contact Andreas and offer to help? He reads this list, I'm sure he'll contact you if your help is needed -- I'm in the impression though he'll manage. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpCimZeIQkQW.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Mon, Aug 16, 2004 at 09:16:24AM +0200, Thomas Viehmann wrote:
> Jeroen van Wolffelaar wrote:
> > packages in contrib are allowed to FTBFS due to missing dependencies in
> > Debian. You may close any FTBFS bugs on filler caused by missing java2
> I think this should be missing *build*-dependencies.
> To me it looks like filler 1.02-2 specifies java-compiler, debhelper as
> build-dependencies.
Hm, indeed, that's a problem. It should build-depend on j2sdk1.{3,4} or
whatever instead...
Lintian should also have given you:
W: filler source: virtual-package-depends-without-real-package-depends
build-depends-indep: java-compiler
You should build=depend: | to
give builders a hint which package you want installed. Plus indeed that
java-compiler isn't a restrictive enough virtual package. On my system,
java-compiler is provided by:
* j2sdk1.4 1.4.1.01-0.1
* jdk1.1 1.1.8v3-1
* j2sdk1.3 1.3.1.02b-2
* kaffe-pthreads-profile 2:1.1.4.PRE1.1.5-11
* kaffe-pthreads 2:1.1.4.PRE1.1.5-11
* kaffe-jthreads 2:1.1.4.PRE1.1.5-11
* jikes-sablevm 1.1.6-2
* jikes-kaffe 2:1.1.4.PRE1.1.5-11
* jikes-gij 1:1.21-2
* jikes-classpath 2:0.09-2
* gcj-3.3 1:3.3.4-3
* gcj 4:3.3.4-2
So, your package should be buildable by _any_ of these. I didn't test
that though.
If filler isn't buildable by some of these, that is indeed a RC bug. As
Thomas said, build-depends need to be specified correctly. Depending on
java2-compiler might be it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
pgpiyytEOB9Dx.pgp
Description: PGP signature
Re: version numbers in testing-proposed-updates (was: current specialities for NMUs)
On Wed, Aug 25, 2004 at 03:28:29PM +0200, Frank K?ster wrote: > Andreas Barth <[EMAIL PROTECTED]> wrote in debian-devel: > > These packages are frozen, i.e. newer uploads to unstable won't go into > > testing. The official way is to upload also a package to testing. To upload > > a package to testing (or: testing-proposed-updates, this are just > > synonyms; tpu in short), it is necessary that the version number of the > > upload is smaller than the current installed package in unstable, and > > larger than the current installed package in testing. So, normally, you > > have to upload a package (directly or in whichever delayed you consider > > appropriate), and the version for testing in one more day delayed. > > Will this also be valid for non-base/standard packages, once everything > is frozen? Yes, unless the sid version already moved on. Versions in testing cannot be higher than those of unstable, so this must be this way. > What version numbers are usually used? If it's no a NMU, does one upload > an artificially high version number (debian revision of -50 or so) to > unstable, just to be sure not to run out of maintainer-upload version > numbers for testing-proposed-updates? Or is it normal to use NMU version > numbers even for maintainer uploads to testing-proposed-updates? You never run out of maintainer version numbers, since can you always add parts. Suppose you're currentlat at -3, then you can of course still upload -4, -5 etc to sid, which is the common way. If you want a sarge backport of fixes to sid, use -3sarge1. If it's a Non-Maintainer backport, use -3.sarge1. With this method, one dot in maintainer revision means NMU (with the before-dot part being the latest MU), zero dots means MU, a property nice to have. Unfortunately, -3sarge1 sorts before -3.1, so if you want as maintainer to backport a NMU to sarge, you're out of luck for straightforward solutions. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > > I'm surprised that your lintian procedures more information then mine. > > According to packages.qa.debian.org is the most recent version 1.23.2, > > I use that version also. The linda program does report also > > the missing manpage, but not the permissions on directories warning. > > > > Which tool do I have to use to make these warnings visible? lintian > According the manual page of lintian is there a check for "huge /usr/share". > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > but lintian didn't complain about that huge /usr/share. > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > Did I use lintian incorret > or is it triggered at a larger /usr/share ? > (then please tell me at which size ) Please tell use HOW you use lintian if you want to know IF you used it incorrect, I cannot magically see how you use lintian. Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and note that due to its new, experimental nature, it is only displayed when you enable informative checks, by means of lintian -I. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp7xbD5fFAug.pgp Description: PGP signature
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
>
> > I'm surprised that your lintian procedures more information then
> > mine. According to packages.qa.debian.org is the most recent version
> > 1.23.2, I use that version also. The linda program does report also
> > the missing manpage, but not the permissions on directories warning.
> >
> > Which tool do I have to use to make these warnings visible?
>
> I don't know if this is related to what happened in this case, but often
> running lintian against the binary package (*.deb) will give different
> results than running lintian against the source package (*.dsc) and
> changes file (*.changes).
>
> I generally use
>
> $ lintian *.{deb,dsc,changes}
Lintian has three type of checks: source checks (dsc), binary checks
(deb) and udeb checks (udeb). While some checks share code, and some
problems are reported in both, most problems can only be detected in
either the binary, or the source.
Running lintian on a .changes file will simply run in on those files
named in it, it isn't needed to also seperately list the .deb and .dsc's
if they are already also in the .changes.
> for normal checking, or
>
> $ lintian -Iv *.{deb,dsc,changes}
>
> if I want it to be more verbose. =)
-v isn't very useful imho usually, but the two option you should
consider are indeed -I, for some checks we didn't dare to enable by
default, and -i, which will give you an explanation for each problem
detected, possible with a hint how to fix it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 12:08:54PM -0600, Wesley J Landaker wrote:
> On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> > On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > > I generally use
> > >
> > > $ lintian *.{deb,dsc,changes}
>
> > Running lintian on a .changes file will simply run in on those files
> > named in it, it isn't needed to also seperately list the .deb and
> > .dsc's if they are already also in the .changes.
>
> You're right; thanks for the clairification. In that case, it might make
> sense to change my habit to "lintian *.changes" and save a few
> keystrokes. =)
Which is exactly what debuild by default does for you. In addition, it
will also add the proper fakeroot magic to dpkg-buildpackage, and, eh,
it's shorter to type than dpkg-buildpackage, so I prefer this one-in-all
script for building my stuff :)
(Package devscripts, in case you're wondering)
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH lintian too hush
Diverting to lintain-maint, where this is more appropriate... On Sun, Aug 29, 2004 at 10:26:13PM +0200, Geert Stappers wrote: > On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > > > According the manual page of lintian is there a check for "huge > > > /usr/share". > > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > > but lintian didn't complain about that huge /usr/share. > > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > > > Did I use lintian incorrect > Oops, indeed I didn't tell that I didn't provide any optional flags. > > > > or is it triggered at a larger /usr/share ? > > > (then please tell me at which size ) > > > > Please tell use HOW you use lintian if you want to know IF you used it > > incorrect, I cannot magically see how you use lintian. > > ( wget > http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb > ) > > lintian conglomerate_0.7.14-1_powerpc.deb > > So no extra flags. That is based on lintian manual page. > >-c, --check > Run all checks over the specified packages. This is the default > action. > > The idea is the use the default action to get _all_ checks. It hides the ones that are more likely to be incorrect and annoying than to actually be useful... > But I was looking for the hugh /usr/share so I tried > > lintian -C hus conglomerate_0.7.14-1_powerpc.deb (...) > But still no sign of the hugh /usr/share -C will limit the number of tests done, rather than doing all. Note that in both of the above cases, the test is performed, but just hidden for you. > > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > > note that due to its new, experimental nature, it is only displayed when > > you enable informative checks, by means of lintian -I. > > Hey a -I flag, lets try it: > > $ lintian -I conglomerate_0.7.14-1_powerpc.deb > I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% > > > Okay, I found what I was looking for > What is a constructive way to solve our different expections > of _all_ checks and "forceing hus check" versus the -I flag? Dunno, -C et al are IMHO to be discouraged, are only for very rare, specialized uses. I'm actually in favour of dropping them from the --help, and in manpage, maybe even move all that advanced stuff to a different manpage/chapter. Regular maintainers shouldn't ever need that option, it's only needed if you're doing some QA stuff or mass-checking, and then you need to read the code anyway... > (next is dutch, native language for me and probably also for Jeroen > Wat is een opbouwende manier om ons verschil in verwachtingen > bij _alle_ test en de "geforceerde hus test" tegenover > de -I optie op te lossen?) I understood the English part fine :), indeed, Dutch is my native language, as you have guessed from my .nl email. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: seek for advice of package regexx
On Sun, Sep 12, 2004 at 12:48:54PM +0100, Qingning Huo wrote: > I think it would be better to use the libpcre3 library, make regexx > easier to maintain, and more up to date. Before I start working on it, > I would like know whether this is the best practice, and whether there > are any pitfalls. As Matthew Palmer already said, it might be non-trivial. However, _not_ doing so is suboptimal for at least two reasons: - security. If a security issue is found in libpcre, a security fix will not propagate automatically into your package - space considerations. If you use the Debian libpcre library, your program will be smaller, both on disk and in memory (due to sharing with other programs using libpcre) And of course maintainability, you don't have to maintain the pcre code and can blaim^Wask the libpcre maintainer about any bugs in it :-) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Suggestions On Getting A Sponsor
On Mon, Sep 27, 2004 at 07:56:37PM -0700, Steve Langasek wrote: > The issue is that providing a package for a webapp that only integrates > with certain webserver packages in Debian splits the userbase between > those who have a reason to want to use your package, and those who have > to do the integration work themselves anyway and won't see any reason > not to download the tarball. Eh, but who's using other webservers than apache anyway? This is a popcon graph for all packages providing httpd: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=apache2-mpm-threadpool%2Cthttpd%2Cdhttpd%2Caolserver%2Capache-perl%2Capache2-mpm-prefork%2Cmzscheme%2Croxen3%2Capache%2Cmathopd%2Caolserver4%2Capache2-mpm-perchild%2Cboa%2Cthy%2Cbozohttpd%2Cfnord%2Capache2-mpm-worker%2Ccaudium%2Capache-ssl&show_installed=on&want_percent=on&beenhere=1 And this is one without the three most used ones (apache, apache-ssl, apache2-mpm-prefork), so you can better distinguish the rest: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=apache2-mpm-threadpool%2Cthttpd%2Cdhttpd%2Caolserver%2Capache-perl%2Cmzscheme%2Croxen3%2Cmathopd%2Caolserver4%2Capache2-mpm-perchild%2Cboa%2Cthy%2Cbozohttpd%2Cfnord%2Capache2-mpm-worker%2Ccaudium&show_installed=on&want_percent=on&beenhere=1 Still a noticeable usage of course, but at the moment, popcon respondents are mainly developers and people following development, which will always show some extra diversity. Besides this, for most package it'd be trivial to configure it for people's own webserver, I know that for my packages, you only need to set something equivalent to 'Alias' (or virtualhost), the rest of the configuration is optional. The real solution is, and there is been talked about, to have some intermediate protocol to say 'make an alias for this to that', that all web applications produce, and all webservers understand (at configure time) to rewrite in their native configuration format. This is an etch project IMHO, as maintainer of several web applications, I think this is something that really should be looked into. > > Certainly some people think that web apps should be packages. I know > > there are plenty of highly useful and popular packages for web apps in > > Debian right now. IMP, Gallery, PHPMyAdmin, LDAPExplorer to name a > > few. While maybe not as polished as some other packages, they work very > > well and provide a valuable service to the Debian community. > > Of those, I've used the IMP packages regularly, have never gotten around > to checking whether the phpmyadmin package was usable for the use I > would have had for it, and have found that the gallery package > specifically does *not* provide the flexibility I needed for per-user > photo galleries. FWIW. This can be fixed, and IMHO a maintainer should look into that. phpbb for example doesn't natively support multiple boards per package, but as maintainer I've patched it so it _does_ support it, with per-board configuration files. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Upgrade version of lostirc and pharmacy, need support
On Wed, Sep 29, 2004 at 07:17:55AM +0200, Amaya wrote: > Martin Braure de Calignon wrote: > > http://www.enseirb.fr/~braurede/deb_dev/pharmacy > > I used to maintain pharmacy, i'll take a look at it if no one has helped > you yet. Oh, and could you please not put the word 'pharmacy' in the subject? I see I fed the original mail to 'learn as spam', and did the same with this mail too, but I just in time saw 'Amaya' as From:, and rescued myself from blacklisting her :). I might not be the only one who is trigger-happy on the word 'pharmacy', especially if it says 'needs support'. A subject of something like: | RFS: pharmacy -- Program to do foo and bar would be quite fine, though. Feel free to ignore me by the way, I'm just another, nowadays unfortunately only, lurker of this list. --Jeroen Who now ponders whether it's actually a good idea to have a single keystroke for 'feed to bayes and delete this message, and add to list of potential to-be-blacklisted people'. -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Package Hijecking?
On Mon, Oct 25, 2004 at 01:45:51PM +0900, Yooseong Yang wrote: > I am not familiar with this situation: > The other DD maintained his package name like mozilla-locale-ko, but > because I have not checked this package thoroughly on debian package list > , I reported ITP and uplodaed the package to the main archive. The package > is actually accepted with the other version (=1.7). The previous version > is 1.6. Fortunately, he does not want to maintain the package. > Any idea about this situation? I just modify the changlog file? You did not hijack the package, see #257126. It was removed before you filed the ITP. It's best to incorporate the changelog of the 1.6-2 version, and I'd also suggest to look at the packaging, and incorporate any fixes made to upstread etc, so that upgrades from 1.6 go smoothly. Btw, packaging this package as a native package as you did is a mistake. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: DD packages overview vs bugs
On Fri, Apr 23, 2004 at 07:59:10PM +0200, GCS wrote: > Hi, > > I have just noticed, that on the summary page of my packages[1] the > already closed bugs still shown in xmms-blursk. On the PTS page I can > see that the bugs are closed, and will be archived in 26 days. Is it > normal, ie why I can't see the same with cvs2svn, where I also have > closed bugs going to be archived, but not showing up at the summary > page? The bugs on developer.php is broken due to merkel being restricted, and on the PTS it's broken too due to some configuration change... Only the BTS has the correct info at the moment. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS (kind of) and newbieish problem; TyopoytaORvelo System MOnitor
On Tue, May 11, 2004 at 01:52:55PM +0300, Juuso T?hk?p?? wrote: > I intend to package and maintain Torsmo, ( http://torsmo.sourceforge.net/ ) > a light and simplistic resource monitof for X. I am in the process of > learning to properly use debian packaging tools, and already managed to make > a package that installs, uninstalls and works correctly, but I can't figure > out what lintian warns me about: > > $lintian -i torsmo_0.15-1_i386.changes > W: torsmo source: changelog-should-mention-nmu > N: > N: When you NMU a package, that fact should be mentioned on the first > N: line in the changelog entry. > N: > W: torsmo source: source-nmu-has-incorrect-version-number 0.15-1 > N: > N: A source NMU should have a Debian revision of '-x.x'. This is to > N: prevent stealing version numbers from the maintainer (and the -x.x.x > N: version numbers are reserved for binary-only NMU's). > > What configs should I fix, or is this normal in some cases? I got from the .changes: Maintainer: Juuso Tähkäpää <[EMAIL PROTECTED]> Changed-By: Juuso Tähkäpää <[EMAIL PROTECTED]> which is the cause. You should write your name in debian/control at 'Maintainer:' in UTF-8 too for the Debian archive scripts to recognise this is the same person (and thus recognise it as a maintainer upload, rather than a Non-Maintainer Upload aka NMU). Historically, only plain ASCII (that is excluding the a with ) is allowed in debian/control, but if you're going to violate that (unwritten) rule (which is quite common and an understandable wish) you should use UTF-8. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > Hi all, > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > otherwise I'd better chance my package's Architecture field before sarge There is, today. Notice that xfree86 itself was also stalled by it... Expect your package to go in tomorrow. Do not simply change the architecture field because one or two architectures are behind, rather, try to research *why* your package doesn't go to testing. In this case, Bjorn's page shows wrong information (Cc'ing him). It said: Adding xfree86-driver-synaptics makes 1 non-depending packages uninstallable on s390: xfree86-driver-synaptics But xfree86-driver-synaptics wasn't in testing to begin with (at least, afaics). Exact reason I don't understand (Sarge's X did have s390), but it doesn't matter anymore. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > [...] > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > > Since xfree86 is Architecture: any, I've been suggested to have the > > same on xfree86-driver-synaptics (during a discussion on #debian-mentors) > [...] > > Personally I'd immediately change the architecture field and change it > back once there is a xserver for s390. - You'll probably have to > pester ftp-master to remove the old s390 binary, otherwise > xfree86-driver-synaptics will be blocked by "out of date on s390". I personally disagree: - it's an ugly workaround - it's hiding problems (s390 failures) - there is no good reason to not support s390, so your removal request might even be rejected (I don't know of course what would really happen, I cannot speak for ftp-master of course). - it adds extra workload to ftp-master, which is unnecessary - it means two extra unnessesary uploads, causing extra load on the buildd's, again, quite unneeded --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Tue, May 11, 2004 at 12:03:38PM +0200, Jeroen van Wolffelaar wrote: > On Tue, May 11, 2004 at 09:50:09AM +0200, Mattia Dongili wrote: > > Hi all, > > > > the subject[1] says it all, will it ever be an xserver-xfree86 for s390? > > otherwise I'd better chance my package's Architecture field before sarge > > There is, today. Notice that xfree86 itself was also stalled by it... > > Expect your package to go in tomorrow. Do not simply change the > architecture field because one or two architectures are behind, rather, > try to research *why* your package doesn't go to testing. In this case, > Bjorn's page shows wrong information (Cc'ing him). It said: Oops, I was wrong... I checked out the xfree86 source package, but not the xserver-xfree86 binary package of it. Indeed, it is not available on s390, and never will, since s390 is a mainframe without input controls. Also, s390 doesn't have any possibility to connect a touchpad to. I don't really know what to do about it, maybe ask d-d (this is a quite tricky problem) or debian-release. Some suggestions I heard: - contact ftp-master to add this one to Packages-arch-specific - make your package FTBFS on s390, and have ftp-master remove the s390 binary. It will propagate nicely then, a FTBFS on an unsupported architecture is possible. But this will make s390 attempt to build it, so isn't really nice to do. So the best thing you can do is ask ftp-master for advice I think. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: for two orphaned packages
On Mon, May 10, 2004 at 04:15:23PM +0200, Andreas Metzler wrote:
> On Mon, May 10, 2004 at 03:07:50PM +0200, Bartosz Fenski aka fEnIo wrote:
> > On Mon, May 10, 2004 at 02:38:37PM +0200, Andreas Metzler wrote:
> > > > Ok now I changed dependencies to xlibmesa-gl-dev, xlibmesa-glu-dev.
> > >
> > > > And I made changes to rules file so now I'm using:
> > >
> > > > -find images -name *.ppm.gz -print0 | xargs -0r rm -f
> > > > -find images -name *.pbm.gz -print0 | xargs -0r rm -f
> > >
> > > > Hope this solves every issue talked on list.
> > >
> > > Too easy. ;-) The wildcard (*.ppm.gz) needs to be quoted, otherwise
> > > the shell will (try to) expand it before find sees it.
> > >
> > > -find images -name '*.ppm.gz'
> >
> > Ok. Done already ;)
>
> Well, I find something new everytime I try. ;-)
>
> cp debian/config.{guess,sub} .
> cp: cannot stat `debian/config.{guess,sub}': No such file or directory
> make: *** [build-stamp] Error 1
>
> "cp debian/config.{guess,sub} ." only works with bash. Use
> "cp debian/config.guess debian/config.sub ."
Also, better depend on autotools-dev, and copy them from
/usr/share/misc/.
That way, they are always uptodate.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 12:03:42PM +0200, Jeremy Lain? wrote: > instance using dh_movefiles (see manpage) if you use debhelper. dh_movefiles is deprecated, use dh_install instead. It has options to keep track of install'd stuff, so that it can warn you if you forget to install some files in any package. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 01:55:59PM +0200, Geert Stappers wrote: > * put the the debian directory online. That makes it easier to check. > ( twice a wget, an untar, an unzip and appling and patch >could be avoid (by you) for your peer reviewers ) You can better use dpkg-source -x on the dsc: extra -x, but it unpacks correctly if: - the basename inside the .orig.tar.gz is different - the diff has a diffent basename - it makes debian/rules executable and, not in the least: it's the preferred, 'offical' way te extract a source package, and you can run lintian on the .dsc too. Comments on the package itself: - Copyright is inadequate, you _need_ to copy the full copyright statement in debian/copyright: > Copyright: > > It's available on the GPL. - This package lacks a copyright statement at all, it is undistributable - Section for the -dev should be libdevel, not devel. See http://packages.debian.org/unstable/ - Are you sure this is optional, and not extra? See http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections - After I debuild'd it, I noticed a new directory libinklevel-0.6.2 inside my libinklevel-0.6.2 directory, something is wrong - This is probably not okay: | cd /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib && rm -fr libinklevel.so && \ | ln -s libinklevel.so.2.0.6.2 libinklevel.so | ldconfig /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib | ldconfig: Can't create temporary cache file /etc/ld.so.cache~: | Permission denied | make[1]: *** [install] Fout 1 I don't know much about library building, but the debian build process should not touch the environment, that includes it should not run ldconfig. Did you read all associated documentation? The NM guide in full, the Packaging Manual in full? You really _need_ to have read them, and yes, it is much text. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One source package and more then 1 deb
On Sat, May 01, 2004 at 03:21:01PM +0100, Colin Watson wrote: > On Sat, May 01, 2004 at 03:04:50PM +0200, Jeroen van Wolffelaar wrote: > > - This is probably not okay: > > > > | cd /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib && rm -fr libinklevel.so && \ > > | ln -s libinklevel.so.2.0.6.2 libinklevel.so > > | ldconfig /tmp/l/libinklevel-0.6.2/debian/tmp/usr/lib > > | ldconfig: Can't create temporary cache file /etc/ld.so.cache~: > > | Permission denied > > | make[1]: *** [install] Fout 1 > > > > I don't know much about library building, but the debian build process > > should not touch the environment, that includes it should not run > > ldconfig. > > And what's it doing messing about in /tmp? That's because I debuilded in /tmp, it uses correctly $(CURDIR) in the makefile :) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upload of a new package
On Wed, May 19, 2004 at 08:59:32AM +0200, Fabio Tranchitella wrote: > Hi, >I'm the mantainer of phpldapadmin, a web-based tool for managing ldap > servers. I'm not (yet!) an official Debian developer, so I asked for a > sponsor. He checked my package and uploaded in the unstable debian > archive about ten days ago... > > Here my questions: > - how long takes the verification process and when will be the package > available in unstable? How can I monitor the state of the package? Whenever somebody of the ftp-master team checks your package, and does the necessary paperwork on it. Usually one to two weeks, but it can be slightly longer. > - A new minor upstream version is available for the package, my sponsor > told me it is better to wait the package enters in unstable before > send the new version, because every upload before this happens "reset > the timer" and I have to wait more time to see my package in unstable. That is only true for unstable -> testing progress, this is _not_ true for NEW processing (what this is). So you can have this uploaded right away, and the newest of the two will apprear in unstable. I don't know exactly, but it might be that there is a potential problem closing bugs with the first upload (both are progressed to unstable simultaneously, and if the older one is refused because the newer one happens to get there first, it's bugs aren't closed). I'm not sure though whether this issue exists. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgp7FoMjclPqS.pgp Description: PGP signature
Re: setgid-wrapper
On Wed, May 19, 2004 at 07:53:46AM -0400, James Damour wrote: > On Tue, 2004-05-18 at 09:03, Steven Augart wrote: > > As you probably know, when a shell sees that it is running a setuid or > > setgid shell script, it detects this because the euid and ruid or egid > > and rgid are different. It "fixes" this by setting the euid to be the > > same as the ruid, and/or egid the same as the rgid, effectively > > turning off the setuid/setgid bit. Huh? This is wrong. It is the kernel who refuses to set the UID or GID on execution of setuid/gid shell scripts. Where did you read that? > Actually, I didn't know that. Thanks for the info! Well, it's false. The shell doesn't do anything special with it. > > But, if the egid and rgid are the same, then the shell script leaves > > them alone. (Indeed, unless it's running as root, it has to leave > > them alone -- it does not have permission to do anything else.) The shell never does anything with them. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpQo9E2KojBd.pgp Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Sat, Dec 21, 2002 at 08:04:05PM +0100, Xavier Antoviaque wrote:
> Hello,
>
> I try to use the convention proposed by Rob Bradford a few weeks ago.
>
> Package name: leo
> Version : 3.10
> License : Python licence
> Upstream Author : Edward K. Ream <[EMAIL PROTECTED]>
> Upstream URL: http://personalpages.tds.net/~edream/front.html
> Package URL : http://foobbs.org/debian
> NM status : first package (no application yet)
> GPG key ID : 75DC 9C3D 5537 8694 A57F 1423 2FB4 F9FF 2AD1 9DF6
> Description : a literate editor with outlines for X-Window
Some remarks, not that I'm not a Debian Developer (yet), but before leo can be
included in Debian, these issues need to be resolved anyway
- The .diff.gz is huge, because you included a number of html files
ripped from a website. Please don't do that this way. You didn't note
the source of the html pages in the debian/copyright file, it's not
sure whether you were allowed to do so (I fail to see a license about
it anywhere, and without license to redistribute those .html files,
it's illegal to do so). You should ask upstream to include
documentation in the package itself.
If you do want to include extra html files, I'd suggest -- if it's
allowed and such -- to either make a separate source package for the
leo-docs package, or include it in the .orig.tar.gz (in the latter
case, you'll need to include in the .orig.tar.gz both the original
.zip file and the .html files, and unpack the zip in your debian/rules
file).
- Not your fault (see date of original message), but a new upstream is
available
- If you include your own manpage (great that you've written one -- did
you sent it upstream already?), as sgml. You included the generated
manpage in the .diff.gz: don't do that, have build it into
debian/, leo.1 is a generated file.
- debian/rules: don't invoke programs with /usr/bin/, but
simply (docbook-to-man)
- You fail to build-depend on debhelper and python
- In debian/control, use ${python:Depends}, in stead of hardcoding the
python dependencies
- I don't think it's priority 'optional', see
http://www.debian.org/doc/debian-policy/ch-archive#s-priorities
- Description: Capitalize it correctly, and don't start it with 'a', but
something like 'Literate editor ...'
- Remove the dh-make generated example postinst.ex et al
- debian/changelog: 'This is my first Debian package' -- Is that
relevant for this very package?
- debian/copyright: it has huge lines, you could reformat them to fit 78
chars
- leo(1): It's /usr/share/doc/, not /usr/doc (was already the case in
2002)
- Is it really necessary to have both .GIF and .ico and .bmp's in
/usr/share/leo/Icons? Also, the 'Thumbs.db' file seems to me as an
artifect of a certain Operating System, and shouldn't be installed in
/usr/share
- When running leo just after installing, I get this:
[EMAIL PROTECTED]:~$ leo
Traceback (most recent call last):
File "/usr/share/leo/leo.py", line 190, in ?
shutil.copyfile('/etc/leo/leoConfig.leo', os.path.join(deb_user_conf_path,
'/leoConfig.leo'))
File "/usr/lib/python2.3/shutil.py", line 38, in copyfile
fdst = open(dst, 'wb')
IOError: [Errno 13] Permission denied: '/leoConfig.leo'
Which indicates to me leo is trying to write to the root filesystem.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
pgp86BNIqS1U4.pgp
Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Mon, May 24, 2004 at 10:08:51PM +0200, Jeroen van Wolffelaar wrote: > On Sat, Dec 21, 2002 at 08:04:05PM +0100, Xavier Antoviaque wrote: > > Hello, > > > > I try to use the convention proposed by Rob Bradford a few weeks ago. > > > > Package name: leo > > Version : 3.10 > > License : Python licence > > Upstream Author : Edward K. Ream <[EMAIL PROTECTED]> > > Upstream URL: http://personalpages.tds.net/~edream/front.html > > Package URL : http://foobbs.org/debian > > NM status : first package (no application yet) > > GPG key ID : 75DC 9C3D 5537 8694 A57F 1423 2FB4 F9FF 2AD1 9DF6 > > Description : a literate editor with outlines for X-Window > > Some remarks, not that I'm not a Debian Developer (yet), but before leo can be > included in Debian, these issues need to be resolved anyway (...) Also, upon installation you should somehow create precompiled python files (*.pyc). I don't know python myself, but there must be some preferred way to do so, iirc there is a (unofficial?) python policy. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpC107K4ojoK.pgp Description: PGP signature
Re: RFS: leo -- a literate editor with outlines for X-Window
On Tue, May 25, 2004 at 12:24:16AM +0200, Xavier Antoviaque wrote:
> On Mon, 24 May 2004 22:08:51 +0200
> Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
>
> > Some remarks, not that I'm not a Debian Developer (yet), but before
> > leo can be included in Debian, these issues need to be resolved anyway
>
> Thanks for your reply, its helps a lot.
You're welcome.
> I repackaged leo, I hope it solves the problems you are pointing out.
I'm doing only a very shallow check now (time to go to bed really :)
> You will find it in http://foobbs.org/debian/leo/
>
> > - The .diff.gz is huge, because you included a number of html files
> > ripped from a website. Please don't do that this way.
>
> I ripped it off. The contents of this documentation are in the
> LeoDocs.leo, anyway.
k.
> > - Not your fault (see date of original message), but a new upstream is
> > available
>
> Fixed.
>
> > - If you include your own manpage (great that you've written one --
> > did you sent it upstream already?), as sgml. You included the
> > generated manpage in the .diff.gz: don't do that, have build it into
> > debian/, leo.1 is a generated file.
>
> Fixed. I also switched to XML DocBook.
>
> As for sending the man-page upstream, I will make a bundle with some
> patches to fix hard-coded paths I needed to change by hand.
ok.
> > - debian/rules: don't invoke programs with /usr/bin/, but
> > simply (docbook-to-man)
>
> Fixed - but this time with xsltproc.
>
> > - You fail to build-depend on debhelper and python
>
> Fixed for debhelper, and for Python there is no build-depend, at least
> in the current package.
building the previous package failed on my system, dh_python seemed to
require python to run. Indeed, dh_python(1) says so.
Since you're still using dh_python, you _do_ need to builddepend on
python. Alternatively, you could also drop dh_python, if you're sure you
don't need anything special.
I don't know python to be honest, so I don't know why dh_python doesn't
generate the .pyc generation code, and whether or not that is bad or
good.
> > - In debian/control, use ${python:Depends}, in stead of hardcoding the
> > python dependencies
>
> I tried to use it, but it gives bad results : it does not detects the
> need for python-tk, and requires python2.3, even if python2.2 can be
> used.
python2.3 seems to be default on Debian Sarge, and python is rumoured to
be broken w.r.t. backwards compatibility and such. Why not drop
python2.2? (Since I'm a python-know-nothing, you might want to ignore my
question :) )
> > - I don't think it's priority 'optional', see
> > http://www.debian.org/doc/debian-policy/ch-archive#s-priorities
>
> I do not see any other category that could fit. Could you be more
> specific ?
I mean, I think it's 'extra', rather than 'optional'. Sorry I was so
cryptic.
According to the quoted URL, 'optional' is for stuff you might
reasonably want by default on a system, I don't think leo fits in that
category (admittingly, quite some optional stuff doesn't fit it very
well, so feel free to ignore this if you think it's really appropriate
to be 'optional'.)
> > - Description: Capitalize it correctly, and don't start it with 'a',
> > but something like 'Literate editor ...'
>
> Fixed. That policy was modified since 2002, isn't it ? I remember being
> careful about this point.
Eh, don't know by heart... Anyway, it's just how the majority of
descriptions are, and if everybody would follow the majority, it'd
become consistent, which is a good think :).
(...)
All cool.
> > Also, upon installation you should somehow create precompiled python
> > files (*.pyc). I don't know python myself, but there must be some
> > preferred way to do so, iirc there is a (unofficial?) python policy.
>
> Yes : there even are autogenerated postinst and prerm scripts by
> debhelper for this. But as Leo has to work with both python2.2 and
> python2.3, I do not see a correct way to handle the generation of .pyc
> for both versions (except packaging two versions of Leo).
This is food for [EMAIL PROTECTED], I really have no clue.
Good work by the way, it seems that you've quite quickly fixed some
details on the package now :).
Since this is a python package, you maybe have better luck asking over
there for a sponsor too, by the way (after you've asked your 2.2 <-> 2.3
question).
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > Hello, > > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? The proper way is to simply not upload to mentors.d.n with 'official' debian revision numbers. Assuming the offical version will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by one, append a mentor-specific part). This way, there is never a clash, you can see from the version number it's an unoffical version. Two alternative approaches: - simply increment debian revision, and use -v appropriately, it doesn't matter certain debian-revisions are never uploaded. Disadvantage: changelog cluttering, usually people won't have those unofficial intermediate versions, and the differences among those are not very interesting usually. If you merge the topmost changelog entry every time, you seemingly have gaps in version numbering according to changelog, not very nice either. - Don't care about m.d.n, simply have your fixed version uploaded with the same version number. m.d.n is unoffical anyway, you in no way have to take care of proper upgrade paths at all. Disadvantage: in bugreports with reportbug, and for the user itself, it's hard to see whether the user/reporter has an unoffical version, or the official one. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Fri, Jun 04, 2004 at 04:26:05AM +0200, Remco Seesink wrote: > The manpage of dput doesn't help me with that. Any suggestions how to get > firebird_1.0.3.orig.tar.gz uploaded? -sa on dpkg-buildpackage (or debuild) See dpkg-buildpackage(1) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why are these packages in testing?
On Mon, Jun 07, 2004 at 12:02:01PM +0200, Andreas Barth wrote: > Hi, > > I came across some strange outputs. For example: > > [EMAIL PROTECTED]:~$ madison aiksaurus > aiksaurus | 1.0.1+cvs.2004.02.20-1 | testing | source > aiksaurus | 1.0.1+cvs.2004.03.15-1 | unstable | source, alpha, arm, hppa, > i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > > There is a current removal suggestion by vorlon: > # 20040509 > # bug #241279 > remove aiksaurus/1.0.1+cvs.2004.02.20-1 > > Why is there only the source in testing? Because 7 out of 9 binary packages of that source are still in testing: http://lintian.wolffelaar.nl/histmadison/?source=aiksaurus&package=&date=2004-06-07 Note that the testing output says removal fails due to buggyness of the package: http://packages.qa.debian.org/a/aiksaurus.html # Trying to remove package, not update it # libaiksaurus-data (alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) # Not considered I guess the textual representation is bogus, otherwise removals can't really have worked before. > Similar, for libapache-mod-filter, there is: > [EMAIL PROTECTED]:~$ madison libapache-mod-filter > libapache-mod-filter | 1.4-5 |stable | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | testing | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > libapache-mod-filter | 1.4-8 | unstable | source, alpha, arm, hppa, i386, > ia64, m68k, mips, mipsel, powerpc, s390, sparc > [EMAIL PROTECTED]:~$ > but there is also a removal suggestion, and the excuses-file on > ftp-master says according to > http://bjorn.haxx.se/debian/testing.pl?package=libapache-mod-filter > that this package is removed today from testing. So, why is this still > there? How many hours after the generation of the excuses list are the > packages really updated? 'today' means 'just before next mirror pulse', i.e., it will be gone after tonight. Testing scripts run just after a mirror pulse, and have effect only upon next one, so there generally is a delay of about 20 hours iirc. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Tue, Jun 08, 2004 at 11:58:26AM +0200, Geert Stappers wrote: > On Fri, Jun 04, 2004 at 10:03:52AM -0700, Matt Brubeck wrote: > > But if the NMU is a new upstream version 1.2, then the correct NMU > > version is 1.2-0.1. This is in the Debian Developer's Reference: > > > > "If it is absolutely necessary for someone other than the usual main- > > tainer to make a release based on a new upstream version then the person > > making the release should start with the debian-revision value `0.1'." > > > > -- DDR 5.11.4.1: Source NMU version numbering > > Okay, that reads like: > If there is no offical Debian maintainer yet, then use -0.1. Policy only discusses verion number rules for uploaded versions, it doesn't discuss version numbers for private use. Use common sense for that, for example, either of the three possibilities I posted earlier (with advantages/disadvanteges even). > Also there is no harm in that it looks a like a NMU, It is confusing, but since it's unofficial, you'll only hurt yourself and your beta-testers. > it _says_ there is no one in Debian maintaining the package. No, this is plainly wrong, the version number an sich doesn't say anything about whether or not somebody in Debian is maintaining the package. Only the Maintainer: field of the latest package in sid days so, possibly with hints to future changes in wnpp. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 changelog?
On Sat, Jun 12, 2004 at 12:02:46AM +0200, Magos?nyi ?rp?d wrote: > Hi! > > Lintian tells me that there are obsolete national charset characters > in debian/changelog, and I have to convert it to UTF-8. > > The national characters are in my name. First I have converted > changelog, then lintian figured out that I do an NMU. So I also > converted control. > > Now I cannot debsign, because I could not properly tell gnupg my name > in UTF-8 encoding (cut&paste did not actually work). > > How did you handle the situation? > (I convert back to latin-2 for the time being, but I am overly > interested in the Right Way.) Use the -e'Your Name <[EMAIL PROTECTED]>' to dpkg-buildpackage, in ASCII (you need to have write your name without any non-ASCII, that is, non-7bit, characters). If you want to write your name in non-7bit characters, you'll need to do so in UTF-8, there is no real policy yet for this issue, but the consensus seems to be it becomes '_if_ you use non-7bit characters, those must be in UTF-8'. So in the latter case, write your name in debian/control in UTF-8 too. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 changelog?
On Fri, Jun 11, 2004 at 11:36:14PM +, Magos?nyi ?rp?d wrote: > A levelez?m azt hiszi, hogy Jeroen van Wolffelaar a k?vetkez?eket ?rta: > > > changelog, then lintian figured out that I do an NMU. So I also > > > converted control. > > > Use the -e'Your Name <[EMAIL PROTECTED]>' to dpkg-buildpackage, in > > ASCII (you need to have write your name without any non-ASCII, that is, > > non-7bit, characters). > > > So in the latter case, write your name in debian/control in UTF-8 too. > > It is already done. Now I have to tell gnupg my name in UTF-8. But how? Use the -k flag of dpkg-buildpackage, see dpkg-buildpackage(1) for details. See debuild(1) if you use that, you can have several of these flags hardcoded there (at least your Key ID, since on your account, that won't change ever). You'll also need it anyway when you're sponsoring. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to use reportbug from inside a chroot?
On Tue, Jul 06, 2004 at 10:50:13AM +0200, Frank K?ster wrote: > Andreas Metzler <[EMAIL PROTECTED]> schrieb: > > > On 2004-07-05 Frank K?ster <[EMAIL PROTECTED]> wrote: > >> while I use woody+backports on my working machine, I keep an up-to-date > >> sid chroot for developping purposes. When reporting a bug I find in the > >> chroot, I have to save it in a file and then rerun reportbug on woody, > >> because I do not have an MTA installed in the chroot. > > [...] > > > > reportbug --smtphost=localhost > > cu andreas > > And this works with exim (woody's exim) installed on localhost, without > an smtp server? No, but you could teach exim to also listen and relay mail incoming from 127.0.0.1:25, just as if it were incoming from /usr/sbin/sendmail. Note that ssmtp also works by relaying mail onwards via SMTP. Since you're in a chroot, you'll _need_ to use some kind of network socket to get mail out of the chroot -- having your MTA listen locally on 25 and use ssmtp is the staightforward way to do so. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: phpbb2 (security RC bug, one-time sponsorship of existing package)
Due to holiday of usualy sponsor, could somebody sponsor http://wolffelaar.nl/~jeroen/phpbb.tar for me? Fixes grave security bug, tested okay, no real changes to package except the new upstream sources of course. Thanks, --Jeroen -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 28 Jul 2004 23:30:39 +0200 Source: phpbb2 Binary: phpbb2-languages phpbb2-conf-mysql phpbb2 Architecture: source all Version: 2.0.10-1 Distribution: unstable Urgency: high Maintainer: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Changed-By: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Description: phpbb2 - A fully featured and skinneable flat (non-threaded) webforum phpbb2-conf-mysql - Automatic configurator for phpbb2 on MySQL database phpbb2-languages - phpBB2 additional languages Closes: 258705 259298 260015 Changes: phpbb2 (2.0.10-1) unstable; urgency=high . * New upstream security release (Closes: #259298, #260015) * Fixed debconf typo, and added Japanese debconf translation, thanks to Hideki Yamane (Closes: #258705) Files: bc07e790346584aeade16748dbd1e03b 639 web optional phpbb2_2.0.10-1.dsc 491304f74504a23293eb1f3bb74c9905 3291318 web optional phpbb2_2.0.10.orig.tar.gz d3e259b75562873d2792e6b50b1c140b 26521 web optional phpbb2_2.0.10-1.diff.gz 396de494f64bbe407a4c5dca0b1da44f 488932 web optional phpbb2_2.0.10-1_all.deb 34b2254ef56b47c26cb56e895781d4cb 32360 web optional phpbb2-conf-mysql_2.0.10-1_all.deb 05d025395a00c398462d2e84dbb2ef5a 2788512 web optional phpbb2-languages_2.0.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCC63l2uISwgTVp8RAjM9AJ9Y6Ft6JLle1oRS6ufh3P1vY3L/0QCggzWr vHgp9CAbUrJwR+Y+fCkHoc0= =alAW -END PGP SIGNATURE- -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to retire a bug tagged wontfix,woody?
On Mon, Aug 02, 2004 at 11:42:49PM -0700, Brian Nelson wrote: > Then downgrade it. There's a mismatch there anyway. A serious bug > should *never* be tagged as wontfix. Either it needs to be fixed or > it's not really serious. This is not true. For example, architecture-dependent data in /usr/share is a serious bug, but if a version in woody has this bug, it is still wontfix: such a bug doesn't render the package nearly unusable, doesn't cause dataloss, isn't a security issue, hence, isn't important enough to risk breaking stuff in woody for.. RC bugs tagged woody (and not sarge or sid) do in no way affect sarge's release, you can safely leave them around for documentation purposes (i.e., letting people know you're aware of the bug in woody, but that it won't be resolved in woody, so people won't file new bugs for it). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: out-of-date-standards-version
On Wed, Aug 04, 2004 at 12:39:22AM +0200, Olivier wrote: > Hi all, > > lintian complains: > > out-of-date-standards-version 3.6.0 > N: > N: The source package refers to a 'Standards-Version' that is starting to > N: get out of date, compared to current Policy. You can safely ignore > N: this warning, but please consider updating the package to current > N: Policy. > > The reason I choose this standsards version, is that I can maintain both a > woody backport and a normal package using this standard. Is that a valid > reason? Your package in sid/sarge needs to confirm to the latest policy version, whatever you put in standards-version. That field is only a reminder to yourself, of what policy version you checked your package. Nothing automatic happens with it, you can technically set it to anything without any practical effect. 3.6.1 has compared to 3.6.0 only a deprecation, with a 'should' (i.e., not 'must'), so you can safely put 3.6.1 and not lying. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
This is debian-mentors stuff, IMHO. Sorry, I don't have time myself to answer this now, this list probably will. --Jeroen - Forwarded message from James Damour <[EMAIL PROTECTED]> - Subject: Re: Please help sorting out which sid updates need to make sarge From: James Damour <[EMAIL PROTECTED]> Reply-To: "James Damour (Suvarov454)" <[EMAIL PROTECTED]> To: Jeroen van Wolffelaar <[EMAIL PROTECTED]> Date: Sun, 15 Aug 2004 11:15:01 -0400 I apologize if you did not intend to have maintainers email you directly, but you didn't specify any other communication mechanism (except waiting for an email next week... I'm trying to be helpful and proactive). I recently adopted the orphaned package named "filler" and uploaded a new version to Sid that hasn't made it into Sarge because it FTBFS. Mind you, the old (orphaned) version **also** FTBFS, so I'm not really sure how it made it into Woody; perhaps it got grandfathered in when the Debian policy on Java was changed. Nevertheless, I wanted to let you know that there is only bugs that the Sid version closes are the "package orphaned" bug and a complaint about the documentation. I don't know if either bug is considered important for the Sarge release, and I don't know the policy on replacing one FTBFS version of a package for another. Perhaps the package should be dropped from Sarge? On Sat, 2004-08-14 at 19:29, Jeroen van Wolffelaar wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > Executive summary: If you maintain one or more packages that are > out-of-sync in sarge, please go to http://www.wolffelaar.nl/~sarge/, > read the guidelines, login, lookup your own packages, and fill in the > questions. > > Full story: > > We are currently quite close to the release of the next Debian version, > Sarge. Dozens of packages are uploaded to sid daily, and it looks like > by far not all of them are going to make it into sarge. > > Currently, there are about 1500 packages that have a different version > in sid than they have in sarge. Bugs are closed when they are fixed in > sid, bugs aren't reported very often if they are only present in sarge, > and not in sid, and sid simply still has more users than sarge. > > This situation has a high risk of letting important bugs slip into the > sarge release, and that is not good. Trying to track bugs that were > fixed in sid but not yet in sarge is very tedious, and also not all bugs > and issues are reported in the BTS. > > A better approach to this issue is to judge manually on all those > package that are out-of-sync whether the sid version contains essential > fixes that really ought to make it into Sarge. For this purpose, I > hereby call on all maintainers that have packages that are out-of-sync, > to let the release team know whether this is the case. 1500 packages is > too much for a few volonteers, since it requires intimite insight on all > the changes made in the package between the sarge and the sid version. > > Please visit http://www.wolffelaar.nl/~sarge/ , the site where this is > administred. Next week the maintainers of those packages of which it is > still unknown whether the sid version contains important fixes will be > asked by mail to provide their judgement. > > Thank you for your cooperation, > - --Jeroen > > - -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] > http://jeroen.A-Eskwadraat.nl > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFBHpsqKN6ufymYLloRAga9AJ0YVRRavXOwe2kLJB3zyZLy1P9AEQCffH2z > L+UoodIklLlEXAdEJBLh6Po= > =xetU > -END PGP SIGNATURE- -- James Damour (Suvarov454) <[EMAIL PROTECTED]> - End forwarded message - -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpCtaHvSdUsv.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > It was my understanding from the Debian Java policy > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > by depending upon the java2-runtime (which is *not* supplied by gcj > 3.3), the filler package is correctly identifying a dependency that > wasn't satisfied on the system of the user in bug 255831. The fact that > there is *NO* package in Debian (main or contrib) that satisfies the > dependency is what causes the FTBFS bug. On the other hand, once the > Free Java hackers catch up, filler should run without modification. filler is in contrib, see http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib packages in contrib are allowed to FTBFS due to missing dependencies in Debian. You may close any FTBFS bugs on filler caused by missing java2 packages in Debian referring to the debian policy, it is acceptable for contrib to FTBFS due to missing dependencies. Your package doesn't propagate to testing at the moment due to missing depends, but this issue is currently being worked on by Andreas Barth. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpeawScfsi1Q.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Sun, Aug 15, 2004 at 06:03:40PM -0400, James Damour wrote: > On Sun, 2004-08-15 at 17:31, Jeroen van Wolffelaar wrote: > > On Sun, Aug 15, 2004 at 05:26:21PM -0400, James Damour wrote: > > > It was my understanding from the Debian Java policy > > > (http://www.debian.org/doc/packaging-manuals/java-policy/x73.html) that > > > by depending upon the java2-runtime (which is *not* supplied by gcj > > > 3.3), the filler package is correctly identifying a dependency that > > > wasn't satisfied on the system of the user in bug 255831. The fact that > > > there is *NO* package in Debian (main or contrib) that satisfies the > > > dependency is what causes the FTBFS bug. On the other hand, once the > > > Free Java hackers catch up, filler should run without modification. > > > > filler is in contrib, see > > http://www.nl.debian.org/doc/debian-policy/ch-archive.html#s-contrib > > > > packages in contrib are allowed to FTBFS due to missing dependencies in > > Debian. You may close any FTBFS bugs on filler caused by missing java2 > > packages in Debian referring to the debian policy, it is acceptable > > for contrib to FTBFS due to missing dependencies. > > OK, good to know. It's in packaging policy, one of the few must reads for maintainers... (others are DFSG, developers-reference, and preferable new-maintainers guide too). > > Your package doesn't propagate to testing at the moment due to missing > > depends, but this issue is currently being worked on by Andreas Barth. > > > I didn't know that. Should I try to contact Andreas and offer to help? He reads this list, I'm sure he'll contact you if your help is needed -- I'm in the impression though he'll manage. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpKBtgagZedN.pgp Description: PGP signature
Re: [jdamour@nycap.rr.com: Re: Please help sorting out which sid updates need to make sarge]
On Mon, Aug 16, 2004 at 09:16:24AM +0200, Thomas Viehmann wrote:
> Jeroen van Wolffelaar wrote:
> > packages in contrib are allowed to FTBFS due to missing dependencies in
> > Debian. You may close any FTBFS bugs on filler caused by missing java2
> I think this should be missing *build*-dependencies.
> To me it looks like filler 1.02-2 specifies java-compiler, debhelper as
> build-dependencies.
Hm, indeed, that's a problem. It should build-depend on j2sdk1.{3,4} or
whatever instead...
Lintian should also have given you:
W: filler source: virtual-package-depends-without-real-package-depends
build-depends-indep: java-compiler
You should build=depend: | to
give builders a hint which package you want installed. Plus indeed that
java-compiler isn't a restrictive enough virtual package. On my system,
java-compiler is provided by:
* j2sdk1.4 1.4.1.01-0.1
* jdk1.1 1.1.8v3-1
* j2sdk1.3 1.3.1.02b-2
* kaffe-pthreads-profile 2:1.1.4.PRE1.1.5-11
* kaffe-pthreads 2:1.1.4.PRE1.1.5-11
* kaffe-jthreads 2:1.1.4.PRE1.1.5-11
* jikes-sablevm 1.1.6-2
* jikes-kaffe 2:1.1.4.PRE1.1.5-11
* jikes-gij 1:1.21-2
* jikes-classpath 2:0.09-2
* gcj-3.3 1:3.3.4-3
* gcj 4:3.3.4-2
So, your package should be buildable by _any_ of these. I didn't test
that though.
If filler isn't buildable by some of these, that is indeed a RC bug. As
Thomas said, build-depends need to be specified correctly. Depending on
java2-compiler might be it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
pgpteNr7v3hY7.pgp
Description: PGP signature
Re: version numbers in testing-proposed-updates (was: current specialities for NMUs)
On Wed, Aug 25, 2004 at 03:28:29PM +0200, Frank K?ster wrote: > Andreas Barth <[EMAIL PROTECTED]> wrote in debian-devel: > > These packages are frozen, i.e. newer uploads to unstable won't go into > > testing. The official way is to upload also a package to testing. To upload > > a package to testing (or: testing-proposed-updates, this are just > > synonyms; tpu in short), it is necessary that the version number of the > > upload is smaller than the current installed package in unstable, and > > larger than the current installed package in testing. So, normally, you > > have to upload a package (directly or in whichever delayed you consider > > appropriate), and the version for testing in one more day delayed. > > Will this also be valid for non-base/standard packages, once everything > is frozen? Yes, unless the sid version already moved on. Versions in testing cannot be higher than those of unstable, so this must be this way. > What version numbers are usually used? If it's no a NMU, does one upload > an artificially high version number (debian revision of -50 or so) to > unstable, just to be sure not to run out of maintainer-upload version > numbers for testing-proposed-updates? Or is it normal to use NMU version > numbers even for maintainer uploads to testing-proposed-updates? You never run out of maintainer version numbers, since can you always add parts. Suppose you're currentlat at -3, then you can of course still upload -4, -5 etc to sid, which is the common way. If you want a sarge backport of fixes to sid, use -3sarge1. If it's a Non-Maintainer backport, use -3.sarge1. With this method, one dot in maintainer revision means NMU (with the before-dot part being the latest MU), zero dots means MU, a property nice to have. Unfortunately, -3sarge1 sorts before -3.1, so if you want as maintainer to backport a NMU to sarge, you're out of luck for straightforward solutions. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > On Tue, Aug 17, 2004 at 12:09:10PM +0200, Geert Stappers wrote: > > I'm surprised that your lintian procedures more information then mine. > > According to packages.qa.debian.org is the most recent version 1.23.2, > > I use that version also. The linda program does report also > > the missing manpage, but not the permissions on directories warning. > > > > Which tool do I have to use to make these warnings visible? lintian > According the manual page of lintian is there a check for "huge /usr/share". > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > but lintian didn't complain about that huge /usr/share. > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > Did I use lintian incorret > or is it triggered at a larger /usr/share ? > (then please tell me at which size ) Please tell use HOW you use lintian if you want to know IF you used it incorrect, I cannot magically see how you use lintian. Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and note that due to its new, experimental nature, it is only displayed when you enable informative checks, by means of lintian -I. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpkOzyKeOO0m.pgp Description: PGP signature
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> On Tuesday 17 August 2004 04:09, Geert Stappers wrote:
>
> > I'm surprised that your lintian procedures more information then
> > mine. According to packages.qa.debian.org is the most recent version
> > 1.23.2, I use that version also. The linda program does report also
> > the missing manpage, but not the permissions on directories warning.
> >
> > Which tool do I have to use to make these warnings visible?
>
> I don't know if this is related to what happened in this case, but often
> running lintian against the binary package (*.deb) will give different
> results than running lintian against the source package (*.dsc) and
> changes file (*.changes).
>
> I generally use
>
> $ lintian *.{deb,dsc,changes}
Lintian has three type of checks: source checks (dsc), binary checks
(deb) and udeb checks (udeb). While some checks share code, and some
problems are reported in both, most problems can only be detected in
either the binary, or the source.
Running lintian on a .changes file will simply run in on those files
named in it, it isn't needed to also seperately list the .deb and .dsc's
if they are already also in the .changes.
> for normal checking, or
>
> $ lintian -Iv *.{deb,dsc,changes}
>
> if I want it to be more verbose. =)
-v isn't very useful imho usually, but the two option you should
consider are indeed -I, for some checks we didn't dare to enable by
default, and -i, which will give you an explanation for each problem
detected, possible with a hint how to fix it.
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH Re: conglomerate_0.7.14-2_powerpc.changes REJECTED
On Sun, Aug 29, 2004 at 12:08:54PM -0600, Wesley J Landaker wrote:
> On Sunday 29 August 2004 11:50, Jeroen van Wolffelaar wrote:
> > On Sun, Aug 29, 2004 at 11:44:57AM -0600, Wesley J Landaker wrote:
> > > I generally use
> > >
> > > $ lintian *.{deb,dsc,changes}
>
> > Running lintian on a .changes file will simply run in on those files
> > named in it, it isn't needed to also seperately list the .deb and
> > .dsc's if they are already also in the .changes.
>
> You're right; thanks for the clairification. In that case, it might make
> sense to change my habit to "lintian *.changes" and save a few
> keystrokes. =)
Which is exactly what debuild by default does for you. In addition, it
will also add the proper fakeroot magic to dpkg-buildpackage, and, eh,
it's shorter to type than dpkg-buildpackage, so I prefer this one-in-all
script for building my stuff :)
(Package devscripts, in case you're wondering)
--Jeroen
--
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Re: RFH lintian too hush
Diverting to lintain-maint, where this is more appropriate... On Sun, Aug 29, 2004 at 10:26:13PM +0200, Geert Stappers wrote: > On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote: > > On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote: > > > > According the manual page of lintian is there a check for "huge /usr/share". > > > Conglomerate 0.7.14-1[1] is about 1.4 Mb with a 1.2Mb /usr/share, > > > but lintian didn't complain about that huge /usr/share. > > > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte. > > > > > > Did I use lintian incorrect > Oops, indeed I didn't tell that I didn't provide any optional flags. > > > > or is it triggered at a larger /usr/share ? > > > (then please tell me at which size ) > > > > Please tell use HOW you use lintian if you want to know IF you used it > > incorrect, I cannot magically see how you use lintian. > > ( wget > http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb > ) > > lintian conglomerate_0.7.14-1_powerpc.deb > > So no extra flags. That is based on lintian manual page. > >-c, --check > Run all checks over the specified packages. This is the default > action. > > The idea is the use the default action to get _all_ checks. It hides the ones that are more likely to be incorrect and annoying than to actually be useful... > But I was looking for the hugh /usr/share so I tried > > lintian -C hus conglomerate_0.7.14-1_powerpc.deb (...) > But still no sign of the hugh /usr/share -C will limit the number of tests done, rather than doing all. Note that in both of the above cases, the test is performed, but just hidden for you. > > Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and > > note that due to its new, experimental nature, it is only displayed when > > you enable informative checks, by means of lintian -I. > > Hey a -I flag, lets try it: > > $ lintian -I conglomerate_0.7.14-1_powerpc.deb > I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86% > > > Okay, I found what I was looking for > What is a constructive way to solve our different expections > of _all_ checks and "forceing hus check" versus the -I flag? Dunno, -C et al are IMHO to be discouraged, are only for very rare, specialized uses. I'm actually in favour of dropping them from the --help, and in manpage, maybe even move all that advanced stuff to a different manpage/chapter. Regular maintainers shouldn't ever need that option, it's only needed if you're doing some QA stuff or mass-checking, and then you need to read the code anyway... > (next is dutch, native language for me and probably also for Jeroen > Wat is een opbouwende manier om ons verschil in verwachtingen > bij _alle_ test en de "geforceerde hus test" tegenover > de -I optie op te lossen?) I understood the English part fine :), indeed, Dutch is my native language, as you have guessed from my .nl email. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
