Re: A sane guess at default Debian mirror for pbuilder
On Sun, 27 May 2007 20:53:18 +0100 Matt Zimmerman <[EMAIL PROTECTED]> wrote: > On Mon, May 28, 2007 at 12:25:50AM +0900, Junichi Uekawa wrote: > > After 6 years or so of setting ftp.jp.debian.org as default for > > pbuilder, I'm finally determined that it shouldn't stay like this. > > So I'd like to have some default guessing to happen. Preferably I > > don't want to ask via debconf, since users should have already > > answered the question at installation-time. > > I think the most accurate method would be to scan the list of > configured apt sources, and choose the first one which matches the > Debian release the user is currently running (via the information > from Releases). If the necessary API isn't available yet, this could > probably be added to python-apt without too much trouble, and might > be useful elsewhere as well. It probably needs to be part of devscripts or build-essential (or a dependency of one of those so that it is always available) and personally, I would much prefer that this didn't rely on python. I don't want to have to add python to a debootstrap chroot just to get this functionality. Emdebian is busy removing perl from 'Essential' and is unlikely to support any python on all except the most powerful embedded devices. (Most devices will be C/C++ with a little dash.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpIyTqLIFXCy.pgp Description: PGP signature
Re: A sane guess at default Debian mirror for pbuilder
On Sun, 27 May 2007 22:42:41 +0300 Lars Wirzenius <[EMAIL PROTECTED]> wrote: > On su, 2007-05-27 at 20:06 +0100, Neil Williams wrote: > > Unless your own mirror supports all Debian architectures, you will > > still need a primary for emdebian-tools. Do you test build your own > > Debian packages against your own mirror? Is that wise? > > I don't use emdebian in any way, so any requirements it has are > irrelevant for which mirror piuparts and pbuilder should use when I > use them. True, but it wouldn't be good for the default to be unusable for cross-building. > However, if I did use emdebian, I would be mirroring > anything I need, and would be rather upset if emdebian tools would > insist on clogging my network connection (which I might not have > while running the tools -- think Debcamp). I understand the situation but most personal/portable mirrors only mirror one or at most a few architectures which makes it unusable for cross-building. You would presumably have to ask in advance which architectures people will need to have available - that isn't particularly useful as a default for all users. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpPMZBDYGBDl.pgp Description: PGP signature
Re: Wanted: introductory page for all teams
Frans Pop <[EMAIL PROTECTED]> wrote: > On Sunday 27 May 2007 01:53, David Nusinow wrote: >> The only thing I've ever heard about helping out with the website is >> that it's a herculean task that no mere mortal should attempt. > > Yes, a complete redesign of the website is a herculean task, but > contributing to specific pages or parts is trivial. Yes, you simply submit a bug report with a patch, and wait for a couple of year for it to be applied. http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=www.debian.org&archive=no&version=&dist=unstable&include=patch Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: A sane guess at default Debian mirror for pbuilder
On Mon, May 28, 2007 at 09:39:31AM +0100, Neil Williams wrote: > Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > However, if I did use emdebian, I would be mirroring > > anything I need, and would be rather upset if emdebian tools would > > insist on clogging my network connection (which I might not have > > while running the tools -- think Debcamp). > I understand the situation but most personal/portable mirrors only > mirror one or at most a few architectures which makes it unusable for > cross-building. You would presumably have to ask in advance which > architectures people will need to have available - that isn't > particularly useful as a default for all users. I'd expect that the majority of emdebian users who have constructed a partial local mirror would be able to deal with the situation. This is all aimed at technical users - so long as our error handing is clear we should be OK. Things like "This is really slow compared to normal downloads from my mirror" are probably just as likely. Things like adjusting Debian mirror URLs to include the requested architecture seem reasonable but for local mirrors I think it would be better to improve the error handing to do things like suggest that the architecture might not be present if it can't find the Packages file. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Re: Wanted: introductory page for all teams
On Mon, May 28, 2007 at 11:56:12AM +0200, Frank Küster wrote: > > Yes, you simply submit a bug report with a patch, and wait for a couple > of year for it to be applied. > > http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=www.debian.org&archive=no&version=&dist=unstable&include=patch > That's simply due to missing regular contributors. Also a few people are still reported as 'main contributor' even if their contribution level reached ground zero years ago. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: introductory page for all teams
"Francesco P. Lovergine" <[EMAIL PROTECTED]> wrote: > On Mon, May 28, 2007 at 11:56:12AM +0200, Frank Küster wrote: >> >> Yes, you simply submit a bug report with a patch, and wait for a couple >> of year for it to be applied. >> >> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=www.debian.org&archive=no&version=&dist=unstable&include=patch >> > > That's simply due to missing regular contributors. I know, and I don't blame anyone for that. But Frans should have known better when he wrote "but contributing to specific pages or parts is trivial". Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: A sane guess at default Debian mirror for pbuilder
On Sun, 2007-05-27 at 19:49 +0200, Frans Pop wrote: > On Sunday 27 May 2007 19:43, Joey Hess wrote: > > d-i uses the following hack to figure out where to download udebs from > > when building installation media: > > Note that this can result in multiple sources. If you want only one, this > hack would need to be refined. I can't help thinking that the code should never be reused. Even if its semantics are correct, the repeated re-parsing and pseudo-parsing with different tools is quite opaque. Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
New package containing binaries with same name as some from the packages cons, pscan and hsffig.
Dear Hwei, Uwe and John, I did not manage to contact you in private (see below), therefore by policy 10.1 I have to move the discussion on debian-devel (copy sent to debian-med). We (the members of the pkg-emboss project on Alioth) have uploaded a new package in the experimental section of Debian, emboss, which provides binary program with similar names as your packages. I would like to discuss what is the best solution to this problem for our users. We have already explored a few possible directions on the debian-med mailing list: http://lists.debian.org/debian-med/2007/04/msg00075.html http://lists.debian.org/debian-med/2007/05/msg0.html (The thread is split on two months) Basically, the plan would be to provide the binaries under their original names in /usr/lib, and symlinks in /usr/bin. With such a setup, a user can set his PATH in order to have access to the original names of the binary programs. However, if I do not get answers, I will suppose that nobody cares about the packages cons, pscan and/or hsffig anymore, and will request their removal rather than complicating the things for the users of EMBOSS. Have a nice day, -- Charles Plessy, Wako, Saitama, Japan - Forwarded message from Charles Plessy <[EMAIL PROTECTED]> - Date: Sat, 28 Apr 2007 18:53:45 +0900 From: Charles Plessy <[EMAIL PROTECTED]> To: Hwei Sheng Teoh <[EMAIL PROTECTED]>, Uwe Hermann <[EMAIL PROTECTED]>, John Goerzen <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: New pacakge containing binaries with same name as some from the packages cons, pscan and hsffig. Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.13 (2006-08-11) Dear Hwei, Uwe and John, We have uploaded a package to experimental, "emboss", and it contains binaries whose name are already "taken" by your packages: cons, pscan and splitter. http://packages.qa.debian.org/e/emboss.html Emboss is a suite of many command line programs, it has web interfaces and people use the program names in scripts. I am therefore quite reluctant to rename the Emboss binaries, as I think that people will just not use the package if I do this. I would like to have your opinion on what to do. The most straightforward would be to swich the priorities of our packages to extra and conflict on each other, but I do not know how to interpret the policy... it this solution acceptable ? Have a nice day, -- Charles Plessy Debian EMBOSS Packaging Team Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: compiling packages
On Sat, May 26, 2007 at 06:14:46AM +0100, Oliver Elphick wrote: > 1. Change the Makefile and/or debian/rules as necessary to add -g to the > compilation options. Most already do that. > 2. In debian/rules, comment out the instruction to strip the binaries > (such as dh_strip). No, use the environment variable instead. Just set DEB_BUILD_OPTIONS=nostrip and dh_strip won't actually strip anything. > Packages are too diverse to give a method that will work for every one. Well for most it is simply set that environment variable, and build the package, and you should have what you want. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRE-maint] Ruby section
Vincent Fourmond dijo [Mon, May 28, 2007 at 11:34:29AM +0200]: > Hello dear debian Ruby developpers ! > > If you are interested in having a ruby section (after all, we make > up nearly half of the interpreter section) and if you didn't do it > yet, please second the proposal for the creation of a ruby section > (bug > #419261). You'll need to send a signed mail, of course. Humh... I am not sure - I think the sections structure is not too useful anyway. I'd rather _join_ back several sections (i.e. Perl, Python, interpreters) into the one most of them really belong to (libs/devel/libdevel). When you install a package (as a user), it's not important to you which language it's written in - And as a programmer, you will very likely look at the name, which contains that information. Besides, that's what Debtags is for. The 'sections' mechanism is IMHO way too limited to be of any real use with such a big set of packages as we have. Just to illustrate my point: [EMAIL PROTECTED]: ~$ grep -ri ^Section /var/lib/apt/lists/ftp.mx.debian.org_debian_dists_unstable_main_binary-i386_Packages | sort | uniq -c 1012 Section: web 1029 Section: doc 113 Section: otherosfs 11 Section: embedded 120 Section: comm 1228 Section: perl 1348 Section: net 1660 Section: devel 1989 Section: libdevel 216 Section: science 247 Section: tex 2496 Section: libs 294 Section: editors 29 Section: shells 305 Section: math 36 Section: news 395 Section: graphics 397 Section: kde 400 Section: gnome 434 Section: interpreters 511 Section: python 514 Section: mail 517 Section: misc 597 Section: sound 63 Section: oldlibs 672 Section: text 75 Section: electronics 862 Section: games 874 Section: admin 90 Section: hamradio 969 Section: utils 978 Section: x11 First of all: Groups with 11 packages, groups with over 2000. Does that seem comparable? Some groups (i.e. tex) are well defined, but there is a lot of potential overlap with very subtle distinctions (i.e. devel/libdevel/libs, perl/net/admin/utils, perl/python/interpreters, x11/kde/gnome, etc.) See you at the Debtags talk at Debconf then ;-) Debtags is already part of the shown package information - I can only hope it gains strength (and developer mindshare). I don't think adding a new section will be of any use. Greetings, [ Cc:ing this to debian-devel, as I think that if any discussion happens regarding this bug, it needs to be project-wide. FWIW, this proposal has 4 seconds already. ] -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgpf3DB1bftcs.pgp Description: PGP signature
Re: New package containing binaries with same name as some from the packages cons, pscan and hsffig.
On Mon, May 28, 2007 at 11:15:31PM +0900, Charles Plessy wrote: > Dear Hwei, Uwe and John, > > I did not manage to contact you in private (see below), therefore by > policy 10.1 I have to move the discussion on debian-devel (copy sent > to debian-med). We (the members of the pkg-emboss project on Alioth) > have uploaded a new package in the experimental section of Debian, > emboss, which provides binary program with similar names as your > packages. Actually, there were two replies to your original email, which raises some concerns over the possible approaches you raised. I did receive those emails, but did not reply because I didn't have anything further to add at the time. > I would like to discuss what is the best solution to this problem for > our users. We have already explored a few possible directions on the > debian-med mailing list: > > http://lists.debian.org/debian-med/2007/04/msg00075.html > http://lists.debian.org/debian-med/2007/05/msg0.html > (The thread is split on two months) > > Basically, the plan would be to provide the binaries under their > original names in /usr/lib, and symlinks in /usr/bin. With such a > setup, a user can set his PATH in order to have access to the original > names of the binary programs. This sounds like the best solution, since these conflicting binaries *are* a part of the EMBOSS suite. I don't think it's a good idea to remove other, standalone packages just because one suite happens to have a conflicting name. The programs in a suite should be used together, and if users don't use the suite, they should be able to use the conflicting names for something else. Perhaps you can use debconf to prompt the user whether to setup the symlinks to the EMBOSS binaries? (Hopefully this is not a wrong use of debconf.) That way, regular users of EMBOSS get the appropriate warning that some binaries may not be available in the default path, and get a chance to change that if they so choose, and users who may want to use the conflicting names for other packages can continue to do so without undue interference. > However, if I do not get answers, I will suppose that nobody cares > about the packages cons, pscan and/or hsffig anymore, and will request > their removal rather than complicating the things for the users of > EMBOSS. [...] One of the larger issues this particular case brings up is what to do with packages that contain binaries with overly-generic names. For example, 'convert' in ImageMagick: it is only an image converter, but the name can easily be used for other kinds of conversion. It seems almost inevitable that one day somebody else will create another program named 'convert'. We should have some kind of mechanism to deal with that. --T signature.asc Description: Digital signature
Bug#426417: ITP: tmexpand -- text-macro processing script to create HTML and SGML documents
Package: wnpp Severity: wishlist Owner: Rafael Laboissiere <[EMAIL PROTECTED]> * Package name: tmexpand Version : 0.1.2.0 Upstream Author : John E. Davis <[EMAIL PROTECTED]> * URL : ftp://space.mit.edu/pub/davis/jed/tmexpand * License : GPL Programming Lang: S-Lang Description : text-macro processing script to create HTML and SGML documents This package contains a text-macro processing script to facilitate the creation of text, HTML and SGML documents. tmexpand will be collaboratively maintained by the Debian JED Group and will be a build-dependency of the forthcoming release of the jed package in experimental. The Debian files are currently in preparation and can be accessed from the DJG SVN repository [1]. [1] http://svn.debian.org/wsvn/pkg-jed/tmexpand/trunk/debian/ Rafael Laboissiere -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.17-2-686 (SMP w/1 CPU core) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New package containing binaries with same name as some from the packages cons, pscan and hsffig.
Le Mon, May 28, 2007 at 08:36:05AM -0700, H. S. Teoh a écrit : > On Mon, May 28, 2007 at 11:15:31PM +0900, Charles Plessy wrote: > > Dear Hwei, Uwe and John, > > > > I did not manage to contact you in private (see below), therefore by > > policy 10.1 I have to move the discussion on debian-devel (copy sent > > to debian-med). We (the members of the pkg-emboss project on Alioth) > > have uploaded a new package in the experimental section of Debian, > > emboss, which provides binary program with similar names as your > > packages. > > Actually, there were two replies to your original email, which raises > some concerns over the possible approaches you raised. I did receive > those emails, but did not reply because I didn't have anything further > to add at the time. Dear Hwei, thank you for your answer. I am sorry that I was unclear in my emails: I was actually waiting a bit more than one month for answers ... Also, I am not saying that packages having conflicting binaries should be removed, just that packages having serious bugs and no answer from the maintainer for a dozen of weeks should be orphaned and either adopted or removed. The way to deal with trivial binary names is indeed challenging and we did not find a good solution for the problem, especially if we want to provide an abstraction layer to the user. For instance, with Debconf, I do not think that we can manipulate the PATH of users which are not yet created, and in the case of EMBOSS, a command line suite of programs, it is likely to be a limitation. I proposed two ideas in the past discussion, mostly for the sake of it, but I admit they are not very convincing: - having the two packages which contain conflicting binaries shipping the same wrapper. - detecting some strong cues for the interest for one package, such as the use of a particular CDD, and try to change the binary names accordingly. In our particular case, in which we have not many users, and apparently non-overlapping userbases, another problem is that any solution is likely to annoy 99.9 % of the users and help 0.1 %... which is not interesting now that we have less than 100 users ! Anyway, for the moment my plan is to implement the /usr/lib workaround, and submit serious bugs next week to pscan and hsffig if I do not get answer... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A sane guess at default Debian mirror for pbuilder
Hi, > > After 6 years or so of setting ftp.jp.debian.org as default for > > pbuilder, I'm finally determined that it shouldn't stay like this. So > > I'd like to have some default guessing to happen. Preferably I don't > > want to ask via debconf, since users should have already answered the > > question at installation-time. > > I think the most accurate method would be to scan the list of configured apt > sources, and choose the first one which matches the Debian release the user > is currently running (via the information from Releases). If the necessary > API isn't available yet, this could probably be added to python-apt without > too much trouble, and might be useful elsewhere as well. I think this is very much useful as a starter. Considering that current apt output is not sufficient (apt-config does not seem to dump sources.list information, and apt-cache policy does not output enough information), it would be a good idea to have APIs for doing it. I am not sure if it should be done at python-apt layer or libapt-pkg, or adding an interface to apt-cache. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pbuilder-maint] A sane guess at default Debian mirror for pbuilder
Hi,
>
> d-i uses the following hack to figure out where to download udebs from
> when building installation media:
>
> grep '^deb[ \t]' $(SYSTEM_SOURCES_LIST) \
> |grep -v '^deb[ \t]cdrom:' \
> |grep -v
> '\(security.debian.org\|volatile.debian.\(net\|org\)\)' \
> |grep '[ \t]main' \
> |awk '{print $$1 " " $$2}' \
> |sed "s,/* *$$, $(SUITE) $(UDEB_COMPONENTS)," \
> |sed "s,^deb file,deb copy," \
> |perl -ne 'print unless $$seen{$$_}; $$seen{$$_}=1' ; \
This chunk of code looks volatile, and vulnerable to changes in mirror
structures, if I duplicated it to pbuilder. I'm now more inclined to
have some common code that can be shared from several applications,
and let apt parse sources.list, rather than parsing sources.list
individually.
regards,
junichi
--
[EMAIL PROTECTED],netfort.gr.jp} Debian Project
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removing 'printtool' from archives
On 5/27/07, A Mennucc <[EMAIL PROTECTED]> wrote: But I think that 'printtool' has outlived its usefullness: its database of printers (that is actually contained in the package 'printfilters-ppd', for some strange reason) is outdated; Have all of the printer files (especially the older ones) in printfilters-ppd been migrated the other printer databases in Debian? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426482: ITP: kaa-base -- Base Framework for Kaa Modules
Package: wnpp Severity: wishlist Owner: Jeremie Corbier <[EMAIL PROTECTED]> * Package name: kaa-base Version : 0.1.3 Upstream Authors: Jason Tackaberry <[EMAIL PROTECTED]> Dirk Meyer <[EMAIL PROTECTED]> * URL : http://freevo.org/kaa * License : GPL Programming Lang: Python, C Description : Base Framework for Kaa Modules Kaa Base provides the base Kaa framework and is an implicit dependency for all kaa modules. The kaa framework includes a mainloop facility with an API for signals and callbacks, timers, process and thread management, file descriptor monitoring (with INotify support), inter-process communication, as well as a rich, practically magical API for asynchronous programming. . The Kaa Media Repository is a set of Python modules related to media. -- Jeremie /* ``Recursive, adj.; see Recursive.'' -- Unknown */ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.20.6dedibox_r7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash pgp24seKYr1TB.pgp Description: PGP signature
Can/should debconf notes still be used?
Hi all, in the past the use of debconf notes has been discussed, and it seemed to be general consensus that they are mostly useless (or misused), but that there are still a couple of legitimate uses which prevent their removal from debconf (or making them a no-op) [1] Now I am at the point where I would like to introduce a new debconf note, and I'd like to request comments before we do that. We are dealing with the cleanup after bug #420390. Briefly, tetex-base's postrm was written under the assumption that teTeX is the only TeX system, and the postrm removes a lot of files below /etc which were installed by older versions of teTeX - but now with the appearance of texlive, these files are conffiles of texlive-* again. Some of these files are essential, texlive-base, texlive-base-bin, or texlive-latex-base won't configure without them. The postrm has been corrected now, but many people have already done the purge. To me, the solution is to resurrect these conffiles without prompting, because prompting doesn't make sense if the only working answer is "yes". Even if I know that "preserve local changes upon upgrade" normally means also to preserve conffile removals - I think this cannot be applied here. I'm also considering to resurrect the non-essential conffiles while on the way, either unconditionally or only when the essential ones were missing, too. Now the question is, how should we notify the user about what we've done? Since this is a violation of the letter of policy, I don't think a remark in NEWS.Debian is appropriate, and I'd like to use a debconf note of priority "high". But notes are considered deprecated. On the other hand, it's not an error, so the error type doesn't seem appropriate... Comments welcome, Frank [1] http://thread.gmane.org/gmane.linux.debian.devel.general/106537/ -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
