Re: dpkg-sig support wanted?
On Tue, Nov 22, 2005 at 05:41:05PM +0100, Petter Reinholdtsen wrote: > > [Marc 'HE' Brockschmidt] > > I'd like to know if anyone cares about using these binary signatures > > I can not really say if I care or not, as I do not really know what > these binary signatures are. Care to send URL to pages explaining the > topic? As per 'apt-cache show dpkg-sig': Website is http://dpkg-sig.turmzimmer.net/ James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpEBswLX1uTA.pgp Description: PGP signature
Re: ITP: ladder.app -- GNU Go frontend for GNUstep
On Wed, Nov 30, 2005 at 01:28:30PM +, Jochen Voss wrote: > On Wed, Nov 30, 2005 at 07:31:21AM -0500, Roberto C. Sanchez wrote: > > On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote: > > > It uses gnugo as its > > > engine and you must have a recent version of gnugo installed in order to > > > run > > > it. > > This statement is unnecessary. You use dependencies to specify that. > > I think that the use of gnugo is a significant piece of information > about the package. When selecting a program to play Go against you > would want to know what opponent (playing strength/style/...) you > will be facing. It would be awkward to find this from the dependency > list and thus should be in the package description. Indicating that gnugo is the engine is relevant, but specifying that a recent version of gnugo need be installed is not. In fact, that part of the description could become invalid depending on the development of both gnugo and ladder.app. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpOCDBYDPUI7.pgp Description: PGP signature
Mail headers (was Re: sarge uninstallable !?!)
On Fri, Dec 02, 2005 at 06:35:19PM +0100, A Mennucc wrote: > That day, Florian Weimer wrote > > By the way, your Mail-Followup-To: header is broken. > > thanks;some time ago I decided to abide by > http://larve.net/people/hugo/2000/07/ml-mutt > but I forgot to fix this account So, shouldn't your Reply-To: header be: Reply-To: [EMAIL PROTECTED], debian-devel@lists.debian.org or Reply-To: debian-devel@lists.debian.org instead of your current: Reply-To: [EMAIL PROTECTED] which is useless since the From: header is used when there is no Reply-To: header. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpDtLxYbln99.pgp Description: PGP signature
Re: not getting CCs from the bugs I reported
On Tue, Jan 03, 2006 at 09:30:44AM -0600, Graham Wilson wrote: > On Tue, Jan 03, 2006 at 12:58:25PM +0100, Josselin Mouette wrote: > > Le mercredi 28 d?cembre 2005 ? 23:49 -0600, Adam Heath a ?crit : > > > You'll only get mails if the sender sends to ###-submitter. Mail sent to > > > just > > > ### is not forwarded, and only stored. > > > > > > This is not a bug in the software, but in the person sending the mail. > > > > I consider this a bug in the software. It's awkward not to receive some > > communications on a bug you submitted. > > I sometimes consider it useful. For instance, when someone has submitted > a patch to the bug, and I am discussing the patch with this individual, > and not the original submitter of the bug report. AIUI, that's where <[EMAIL PROTECTED]> comes in handy. You could send the email to the bug via that alias and then CC the person you're discussing the patch with. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpkbE3C7W7hx.pgp Description: PGP signature
Re: Aptitude question
On Sat, Jan 07, 2006 at 12:51:55AM +0100, Jiří Paleček wrote: > On Wed, 04 Jan 2006 19:50:14 +0100, Linas Zvirblis <[EMAIL PROTECTED]> wrote: > > >Jiri Palecek wrote: > >>How does aptitude decide which one to choose? Shouldn't it > >>prefer to do something that won't break other packages? Or should > >>it ask the user for help? > > >As for your problem, you must provide way more information than just "it > >does > >not work" in order to get help. There are at least five different versions > >of > >aptitude you could be using on whatever version of Debian you use. Most of > >us > >cannot read minds, especially over the Internet. > > If you had read (at least the written protion of) my mind more carefully, > you would realize that I have never said "it does not work". I thought it > more as a feature request (or idea) than bug report. I was asking about > how is aptitude supposed to solve such situations, beacuse it isn't clear > if it really should try to guess the correct packages to install. The aptitude in unstable and testing has a feature that lists suggested ways to fix broken packages. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpRb0wCUy8Xl.pgp Description: PGP signature
Bug#350231: ITP: libsocket++ -- a family of C++ classes for Socket Operations
Package: wnpp Severity: wishlist Owner: [EMAIL PROTECTED] * Package name: libsocket++ Version : 1.12.12 Upstream Author : Herbert Straub <[EMAIL PROTECTED]> * URL : http://www.linuxhacker.at/socketxx/download * License : Description : a family of C++ classes for Socket Operations The socket++ library defines a family of C++ classes that can be used more effectively than directly calling the underlying low-level system functions. One distinct advantage of the socket++ is that it has the same interface as that of the iostream so that the users can perform type-safe input output. Copyright Notice: - Copyright (C) 1992-1996 Gnanasekaran Swaminathan <[EMAIL PROTECTED]> Permission is granted to use at your own risk and distribute this software in source and binary forms provided the above copyright notice and this paragraph are preserved on all copies. This software is provided "as is" with no express or implied warranty. Copyright Notice: - Portions Copyright (C) 2002-2003 Herbert Straub for all my changes (see ChangeLog) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-debil-3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) signature.asc Description: Digital signature
Re: Bug#350231: ITP: libsocket++ -- a family of C++ classes for Socket Operations
On Fri, Jan 27, 2006 at 07:52:35PM -0800, Russ Allbery wrote: > James Vega <[EMAIL PROTECTED]> writes: > > > Copyright Notice: > > - > > Copyright (C) 1992-1996 Gnanasekaran Swaminathan <[EMAIL PROTECTED]> > > > Permission is granted to use at your own risk and distribute this > > software in source and binary forms provided the above copyright notice > > and this paragraph are preserved on all copies. This software is > > provided "as is" with no express or implied warranty. > > That license doesn't appear to grant the right to distribute modified > works. If I'm unable to contact the original upstream for clarification/updating the license, this could go into non-free, right? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpxUY0zIEQaA.pgp Description: PGP signature
Bug#310019: ITP: fish -- a friendly interactive shell
Package: wnpp Severity: wishlist Owner: James Vega <[EMAIL PROTECTED]> * Package name: fish Version : 1.9.1 Upstream Author : Axel Liljencrantz <[EMAIL PROTECTED]> * URL : http://roo.no-ip.org/fish/ * License : GPL Description : a friendly interactive shell Fish is a shell geared towards interactive use. Its features are focused on user friendliness and discoverability. The language syntax is simple but incompatible with other shell languages. Fish also includes some code which falls under the following licenses: License for wcslcat and wcslcpy fish also contains small amounts of code under the BSD license, namely versions of the two functions strlcat and strlcpy, modified for use with wide character strings. This code is copyrighted by Todd C. Miller. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. License for XSel The XSel command, written and copyrighted by Conrad Parker, is distributed together with fish. It is Copyright (C) 2001 Conrad Parker <[EMAIL PROTECTED]> Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-debil-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mail headers (was Re: Centralized darcs)
On Thu, Aug 03, 2006 at 12:28:35AM +0200, Magnus Holmgren wrote: > On Thursday 03 August 2006 00:11, Josselin Mouette took the opportunity to > say: > > Le mercredi 02 août 2006 à 15:34 -0500, John Goerzen a écrit : > > > > Ok, third time. Please do not do that: > > > > To: George Danchev <[EMAIL PROTECTED]> > > > > CC: debian-devel@lists.debian.org > > > > > > Then SET YOUR HEADERS to reflect that, like everyone else does. > > > > Which headers? > > > > (If you are talking about Mail-Followup-To, this is a non-standard > > header that many MUAs don't implement.) > > Yeah, and privately setting Reply-To to the list is almost as bad as when the > list manager software does it. The whole point of Reply-To is to allow the sender to specify where replies should be sent. There's no need for Mail-Followup-To. I agree that the list manager shouldn't set it, but there's nothing wrong with it being privately set. If you want your reply sent somewhere other than where the sender thinks it should be going, then you should be cognizant enough to change where the email is being sent and wouldn't care about Reply-To or M-F-T anyway. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Code of Conduct on the Debian mailinglists
On Fri, Aug 04, 2006 at 03:04:05PM +1000, Ben Finney wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > > You know, I use a mail program. Replying to people is in my fingers > > as "hitting a button". A very specific button, especially for that > > purpose. I expect my MUA to Do The Right Thing (TM). > > Most MUAs will do the right thing when you reply; they'll send a > message to the single person who wrote the message. The person who > wrote the message can indicate where this single-person reply should > go, by specifying header fields such as 'From' and 'Reply-To'. If you're partaking in a discussion on a mailing list, the replies should generally be sent back to the list. If I want to respond privately to a post, I should be aware that I'm breaking away from the public discussion and be aware enough to send the email to the address provided in the From field. > Many MUAs also have a separate specific facility, for replying to > *every* address related to the discussion. This is fine for a group of > individuals, but problematic for a mailing list, since one of those > addresses will be the mailing list address itself, and then some > people get two copies -- one individually (which usually arrives > first, since it has less processing time) and one from the mailing > list. This is something that should be solved on the list manager side by not sending a duplicate of the email when it can see that an email was already sent to an address it recognizes. In fact, some of the lists I'm subscribed to do this. > We can't use the mailing list address for this: that misses anyone > who's not subscribed but wants followup messages. Then they set Reply-To to both the list address and their own. > We can't use the Reply-To field in an existing message: that is > specifically for *individual* responses to the person posting the > message. This field provides a general mechanism for indicating any *mailbox(es)* to which responses are to be sent. > This is completely wrong for followup messages intended for > all interested parties. In the second case, an author may wish *additional persons to be made aware of, or responsible for, replies.* A somewhat different use may be of some help to "text message teleconferencing" groups equipped with automatic distribution services: *include the address of that service in the "Reply- To" field of all messages submitted to the teleconference;* then participants can "reply" to conference submissions to guarantee the correct distribution of any submission of their own. Above quotes are from Section 4.4.3 of RFC882, the description of the Reply-To / Resent-Reply-To fields (emphasis mine). > There *is* no header field recommended by the IETF that meets this > need. We use Mail-Followup-To because it actually meets the need > described above. Reply-To specifically meets this need. It is even addressed in the actual description of the field. If you want to send a private reply, the From field gives you plenty of information. Otherwise, the Reply-To field provides all the information you need. There's no reason to add an ad hoc header to 'fix' something that isn't broken. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Please comment the license of vim manual and reference
On Mon, Aug 21, 2006 at 06:42:30PM +0200, Florian Weimer wrote: > * Carlos Z. F. Liu: > > > [2] http://lists.debian.org/debian-legal/2004/03/msg00226.html > > This talks about a different OPL, not the VIM one. This may actually be a typo in the Vim documentation. The help specifies that it uses the Open Publication License (the same license used by Steve Oualline for his Vim book) yet the URL is for the Open Content License. Both license texts use the OPL acronym, which may be the cause of the confusion. There's an open bug against Vim (#384019). I'll bring up the inconsistency with Bram and add his response to the bug report. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: transitioning config files between two packages
On Tue, Sep 12, 2006 at 05:21:50PM -0700, Steve Langasek wrote:
> On Wed, Sep 13, 2006 at 12:40:33AM +0200, sean finney wrote:
> > also, if you have an answer to the original question it'd be
> > appreciated. i'd really really like to avoid using ucf, since there's
> > something like 40 conffiles shared between the packages. but having
> > asked on #d-d a few times as well as here and not having heard anything,
> > i'm afraid i'm going to have to bite the bullet on this one as frank
> > suggests.
>
> After an upgrade and answering all of the conffile prompts, does
> /var/lib/dpkg/info/nagios-plugins.conffiles still exist and reference these
> files? Depending on what dpkg is really doing here, it may well be possible
> to handle the conffile transfer in maintainer scripts. (And I thought
> dpkg.org once had recipes for exactly this, but unfortunately the site has
> been down for some time now. :/)
It should just be a matter of removing the files from the old package
and letting the new ones take their place (with a backup if there are
any user changes). A little grepping around in /var/lib/dpkg/info
turned up this snippet for removing conffiles.
nagios-plugins.preinst:
rm_conffile() {
CONFFILE="$1"
if [ -e "$CONFFILE" ]; then
md5sum="`md5sum \"$CONFFILE\" | sed -e \"s/ .*//\"`"
old_md5sum="`sed -n -e \"/^Conffiles:/,/^[^ ]/{' $CONFFILE'{s/.*
//;p}}\" /var/lib/dpkg/status`"
if [ "$md5sum" != "$old_md5sum" ]; then
echo "conffile $CONFFILE has been modified by you."
echo "Saving as $CONFFILE.dpkg-bak ..."
mv -f "$CONFFILE" "$CONFFILE.dpkg-bak"
else
# conffile isn't modified and will be restored in nagios-plugins-*
rm -f "$CONFFILE"
fi
fi
}
case "$1" in
install|upgrade)
if dpkg --compare-versions "$2" le "$OLDVERSION"; then
rm_conffile "/etc/file1"
fi
esac
James
--
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Bug#389598: ITP: xpbiff -- animated mail monitor on X with popup notification
On Tue, Sep 26, 2006 at 07:29:05PM +0200, Gernot Salzer wrote: > Copyright: > > * xpbiff - popup biff for X > * > * Author: Kazuhiko Shutoh, 1993 > * > * Permission to use, copy, modify and distribute without charge this > software, Doesn't the 'without charge' bit violate DFSG #1? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: locales broken?
On Thu, Apr 20, 2006 at 11:28:11PM +0200, Bastian Venthur wrote: > Hi Devs, > > I know some weeks ago we had some major change in some package (I don't > remember) which broke my locales. I am using UTF-8 (German) but my > system is acting quite strange after the upgrade of the (unknown) package: > [snip] > > My locale is still set to UTF-8 (German) but: > > $ env | grep -i lang > $ Are you sure that isn't being set by one of the files your shell sources during initialization? That was the case for me. > I don't know which package to blame, so can somebody give me a hint and > maybe a workaround? One solution is to set the proper locale in /etc/environment and ensure /etc/pam.d/*dm uses pam_env (this is what I did). Another, probably better, solution is to set the proper locale in ~/.xsession since that will affect only you instead of everyone that uses the computer. HTH, James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
On Fri, Apr 21, 2006 at 08:36:10AM -0500, Manoj Srivastava wrote: > Hi, > > Here is my solution for using vim + script as a pager; similar > mechanisms can be used to use plain vim as PAGER as well. > [snip script] There is already a less.sh that does this, which is in the same directory (/usr/share/vim/vimcurrent/macros) as less.vim. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: fonts prbl in sid
On Mon, Apr 24, 2006 at 11:22:42AM +0200, A Mennucc wrote: > hi > > I use sid and Gnome ; I upgraded my box (after 3 weeks in which I did > not have time to) ; now I have serious problems with fonts. Have you reconfigured xserver-xorg? As part of the modular Xorg update, the directories the fonts reside in have moved. Your xorg.conf may still be pointing to the old directories. Refer to <http://wiki.debian.org/Xorg69To7> for other side-effects you may experience from the upgrade. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.
On Mon, Apr 24, 2006 at 06:13:11PM +0200, Bernhard R. Link wrote: > * Manoj Srivastava <[EMAIL PROTECTED]> [060424 17:39]: > > > > > Package gnus, version x.y-z.dfsg. > > > That way its clearly marked that gnus is modified to be dfsg free, > > > and you dont change any source/package name. A lot of other packages > > > in Debian already go this way, I dont see why gnus can't do it. > > > > In Debian, source package components have precise meaning. > > The package name is Gnus, and the version you are referring to is the > > "upstream" version. In case you are not aware, that implies that > > this is a source package for an upstream release versioned > > x.y-z.dfsg -- which in turn implies that the upstream author has > > created a DFSG free version, perhaps unreleased, for Debian. > > > > I think pretending with a fake upstream version that this is > > the same Gnus upstream packages is misleading at best, and deceptive > > at worst. > > Repackaging upstream software is a common way. It is even documented in > the Developer's reference how those are supposed to handled. > (i.e. only remove files, not add some; the .diff.gz should contain some > README describing how the file can be reproduced, and things like that) > > On the other hand a different source package name has also a specific > meaning. It means it is a different source package, which means it is > a differnt upstream or a different package. Unless you want to fork > the package or add other files, changing the source name is deceptive. Isn't it already a fork? The source package is not the same as the one being shipped by upstream. Hence Manoj's desire to use a different source package name to correctly convey the fact that the source package is not what is being shipped by upstream, but a modified version that meets the requirements of the DFSG. How is it deceptive to rename the source package when it is _not_ the same as the upstream source? James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote: > On Tue, 9 May 2006 22:49:36 +0200, Bill Allombert <[EMAIL PROTECTED]> said: > > Hubert Chan <[EMAIL PROTECTED]> > >alsaplayer-alsa > >alsaplayer-common > >alsaplayer-gtk > > Hmm... alsaplayer-common Depends: on "alsaplayer-alsa | > alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface". Is this > really a problem? The problem is that all three packages Depend on each other as seen from grep-dctrl -sPackage,Depends -FPackage -e 'alsaplayer-(alsa|common|gtk)' Package: alsaplayer-alsa Depends: libasound2 (>> 1.0.9), libc6 (>= 2.3.5-1), alsaplayer-common (= 0.99.76-7) - Package: alsaplayer-common Depends: libc6 (>= 2.3.5-1), libflac7, libgcc1 (>= 1:4.0.1), libid3tag0 (>= 0.15.1b), libmad0 (>= 0.15.1b), libmikmod2 (>= 3.1.10), libogg0 (>= 1.1.2), liboggflac3, libsndfile1 (>= 1.0.2-1), libstdc++6 (>= 4.0.1), libvorbis0a (>= 1.1.0), libvorbisfile3 (>= 1.1.0), zlib1g (>= 1:1.2.1), alsaplayer-alsa | alsaplayer-output, --- alsaplayer-gtk | alsaplayer-interface -- Package: alsaplayer-gtk Depends: libc6 (>= 2.3.5-1), libgcc1 (>= 1:4.0.1), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.10-4), libstdc++6 (>= 4.0.1), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxi6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1, alsaplayer-common (= 0.99.76-7) - There's no real reason that alsaplayer-common needs to Depend on an alsaplayer-output variant or an alsaplayer-interface variant. As a user, if I just want to look at the common files for some reason, I sholudn't need to install alsaplayer-(output|gtk). Those would be fine as Recommends. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 01:41:56PM -0400, Hubert Chan wrote: > On Wed, 10 May 2006 09:04:14 -0400, James Vega <[EMAIL PROTECTED]> said: > > > On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote: > >> Hmm... alsaplayer-common Depends: on "alsaplayer-alsa | > >> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface". Is > >> this really a problem? > > My question, which I guess wasn't clear, was whether the circular > dependency is still a problem if one of the dependencies in the cycle is > an or'ed dependency. As far as I know, yes, they are still a problem. > [...] > > > There's no real reason that alsaplayer-common needs to Depend on an > > alsaplayer-output variant or an alsaplayer-interface variant. As a > > user, if I just want to look at the common files for some reason, I > > sholudn't need to install alsaplayer-(output|gtk). Those would be > > fine as Recommends. > > alsaplayer-common contains the main alsaplayer binary > (/usr/bin/alsaplayer), which does not function without an > alsaplayer-output and alsaplayer-input plugin. So yes, it really does > depend on these. (I would have named alsaplayer-common something > different -- maybe alsaplayer-bin, or just alsaplayer, but that was what > it was called when I inherited it.) Ah, yes, I didn't take a look at the packages as well as I should have. Taking a look at the package contents, it seems like changing the alsaplayer-(output|input) variants to Recommending alsaplayer-common would work fine. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: apt-get wants to remove hotplug?
On Mon, Oct 10, 2005 at 02:37:53PM -0400, Alejandro Bonilla wrote: > Hi, > > In Sid, apt-get wants to remove hotplug. > > Is udev replacing it for good or this is just b0rken? From udev's changelog (available online at <http://packages.debian.org/unstable/admin/udev>): * Added support for coldplug and merged the hotplug scripts left. Switched from udevstart to udevsynthesize. (Closes: #329226) * Added conflicts with hotplug and with module-init-tools releases without support for /etc/hotplug/blacklist.d/. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpyA3RafmiKk.pgp Description: PGP signature
Re: Automated mailing to all maintainers of packages depending on X?
On Fri, Oct 14, 2005 at 04:47:26PM +0200, Frank Küster wrote: > Hi, > > does anybody know about a ready-made script that would extract all > package names and maintainers of packages depending on X from the > Packages file, and send e-mails to them, replacing the package name for > some boilerplate text in a text I feed it: I'm not sure about a ready-made script, but it shouldn't be too difficult to write one that uses whodepends(1) from the devscripts package. Example output: % whodepends xserver-xorg Dependent maintainers for xserver-xorg: Petter Reinholdtsen <[EMAIL PROTECTED]> (ldm) Mattia Dongili <[EMAIL PROTECTED]> (xfree86-driver-synaptics) Debian X Strike Force (xdmx xserver-common xserver-xorg-dbg x-window-system-core) HTH, James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> pgpsH8yIrP7fG.pgp Description: PGP signature
Re: How to cope with patches sanely
On Wed, Feb 20, 2008 at 11:09:03PM +0100, sean finney wrote: > On Wednesday 20 February 2008 05:22:08 pm Manoj Srivastava wrote: > > > Yes, just like I want to have feature branches instead of one gigantic > > > debian branch. > > > > I use my CSM to provide me the changeset: > > baz diff > > > > Indeed, I can get diffs between branch A and branch B -- how do > > you do that using quilt? Get diffs between arbitrary branches? Trivial > > using my scheme. > > we discussed this on irc, but for posterity i'll say it here too: > > the you could think of each individual quilt patch as a "feature diff", thus > the quilt equivalent of a "feature branch" would be the (ideally) pristine > source plus the diff in question. so you have explicitly the comparison > between the feature branch and the source by opening the quilt patch in a > pager. to compare the "feature branches" with each other, you could just do > something like "interdiff patch1 patch2". The difference here being that feature branches are, in my experience, changes against the pristine upstream source. The merging of different feature branches is done in some integration branch. Quilt patches are a dependent series where the merging of changes is inherent in the patch ordering. Thus it's easier to get an "upstream ready" patch from $vcs than from a series of interdependent patches. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Thu, Feb 21, 2008 at 04:23:10PM +0100, martin f krafft wrote: > also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]: > > The difference here being that feature branches are, in my experience, > > changes against the pristine upstream source. The merging of different > > feature branches is done in some integration branch. Quilt patches are > > a dependent series where the merging of changes is inherent in the patch > > ordering. Thus it's easier to get an "upstream ready" patch from $vcs > > than from a series of interdependent patches. > > ... unless feature branches interdepend and you have to store > dependency information somewhere. Each feature is still a separate candidate for inclusion upstream. If you have features A and B, which touch similar files and are therefore interdependent *in your tree*, the patches sent upstream still need to be a diff against their vanilla upstream source. Either you maintain the patches purely against vanilla upstream initially and perform your own merging when you prepare the Debian package or you maintain dependent patches and rediff against upstream's vanilla source before sending the patch their way. Whether using $vcs or $patch_manager, there is going to be some manual work to a) get a patch that is purely against vanilla upstream and/or b) rediff B when A is accepted upstream. You're just changing when you do the work. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Version numbering for security uploads of native packages
On Wed, Mar 19, 2008 at 07:54:46PM +0100, Luk Claes wrote: > Bas Wijnen wrote: > > On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote: > >> Bas Wijnen <[EMAIL PROTECTED]> writes: > > >> We have other ways of tracking that information than the version, though. > > > > Yes, and I don't really care, I just think going from +s1+nmu1 to +s2 > > seems to be doing things that it doesn't (revert the NMU). > > Strange reasoning as 1.0-0.1 followed by 1.1 is also not reverting an > NMU perse... Except that 1.1 is a MU unlike a security upload. One can expect that a decision was made about including (or not) the NMU in the next MU upload. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
On Mon, Apr 07, 2008 at 08:14:19PM +0200, Peter Jordan wrote: > but the repositories does not need to be official debian services, only > the keyrings should be available over the official debian repository. You can get the keys for those sites yourself and add them to the apt keyring. Backports.org even gives you explicit instructions on how to do that. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Are Sha* checksums accepted by dak ?
On Mon, Apr 14, 2008 at 11:08:41PM +, Dirk Eddelbuettel wrote: > Raphael Hertzog debian.org> writes: > > Anthony Towns has applied a fix to dak and Format: 1.8 is accepted now. > > He also resurrected the uploads which have been rejected due to this check > > only. > > I am seeing my uploads rejected too as of right now. I just got back from a > short trip and was trying to fix some bugs. > > Is a dpkg-dev downgrade the best option? If you're using debsign (from devscripts), then you need also need to upgrade devscripts to 2.10.25 as previous versions didn't handle the newer changes Format properly. Other situations to be careful of are using debrsign (remote debsign must be updated) and building packages in a sid chroot on a non-sid system. Basically, make sure you're aware of which package versions you're actually using. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Wed, Apr 16, 2008 at 05:51:48PM +0200, Andreas Tille wrote: > On Wed, 16 Apr 2008, Adam D. Barratt wrote: > >> fwiw, this was mentioned in the recent Misc Development News post to d-d-a. > > Yes, but I expect an up to date pbuilder to contain everything I > need. Thinking about it chances are good that the GPG key is not > copied to the building chroot and my assumption was just wrong and > the local devscripts are involved in finally preparing the package. > I never have really thought about this ... Signing generally isn't performed in the pbuilder chroot. The only reason devscripts would be installed into the chroot is if the package you're building Build-Depends on it or you explicitly installed it into the chroot. You're either running debsign on your own after the build is complete or telling pbuilder to automatically sign the package. In either case, debsign is being invoked outside of the chroot in your native environment. Therefore you need to make sure you have devscripts 2.10.25 (or your own backport if you aren't running sid) in that environment. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 07:04:39AM -0400, Roberto C. Sánchez wrote: > On Thu, Apr 17, 2008 at 08:48:21AM +0100, Adam D. Barratt wrote: > > 2.10.25 should migrate to testing over the weekend, so hopefully a bpo > > package won't be too much longer. In the meantime it's fairly easy to > > backport yourself, as several people have already done, or simply copy the > > new script over from an unstable machine. Other than the update for the new > > .changes file format, there have been relatively little changes to debsign > > since the version in etch, and those have all been bugfixes. > > > IMO, that sort of misses the point. While I maintain quite a few > packages in Debian, the only places I run unstable/testing are in one VM > (for testing/reproducing/fixing bugs that I cannot reproduce in stable) > and in some chroots. The point is that I should be able to build my > packages inside of a pbuilder or other type of chroot, sign the package > on my host system and be reasonably sure that my package will be > accepted into the archive. If the archive software breaks compatibility > with the current stable release of (insert name of whatever tool is > affected, specifically devscripts in this case), then it looks bad on > Debian. You're mixing stable and unstable tools. You have to expect that you may run into incompatibilities -- that happens with feature development. As far as I know, we only require that *upgrades* from one stable release to the next stable release will work, not intermingling tools between them. The only thing about this that looks bad, IMO, is that we had some bad timing on uploads (which happens in unstable) and that we have developers who can't pay attention to debian-devel-announce. devscripts (and the debsign tool) is simply a convenience package and not having an up-to-date version of the package does not prevent you from doing your work. You can just as easily run dpkg-buildpackage in a chroot to build your packages and that has been generating proper signed .changes files the entire time. On the plus side, debsign is now more resilient to future changes in the Format of .changes files (as will mergechanges in the next upload). This only changes *when* the reject happens though (at debsign run instead of at upload), not whether it happens at all. Hopefully other tools which parse the .changes file have also learned from this experience and taken similar steps to prevent operating on Formats they don't understand. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Thu, Apr 17, 2008 at 12:56:01PM -0400, Roberto C. Sánchez wrote: > On Thu, Apr 17, 2008 at 11:34:06AM -0400, James Vega wrote: > > On the plus side, debsign is now more resilient to future changes in the > > Format of .changes files (as will mergechanges in the next upload). This > > only > > changes *when* the reject happens though (at debsign run instead of at > > upload), not whether it happens at all. Hopefully other tools which parse > > the > > .changes file have also learned from this experience and taken similar steps > > to prevent operating on Formats they don't understand. > > > This certainly good. However, perhaps dak should have been changed to > accept both format versions (1.7 and 1.8), instead of just rejecting the > old one right away. This isn't a problem with dak. It was one with debsign. debsign operates on the generated .dsc and .changes files from a build instead of signing the .dsc and then creating the .changes as part of the build like dpkg-buildpackage does. To do so, it must change information in the .changes file regarding the size and checksum of the .dsc file. Since that wasn't being done, dak rightly rejected the uploads because the size and checksums listed didn't match that of the uploaded .dsc file. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
NMU versioning (was: DEP1: Clarifying policies and workflows for Non Maintainer Uploads)
On Thu, Apr 24, 2008 at 09:42:59PM +0200, Bas Wijnen wrote: > This DEP is available on the Debian Wiki[1]. "The version must be the version of the last upload, plus +nmuX, where X is a counter starting at 1." The above was added to the DEP to "match dch" but dch only uses that format for native NMUs as per the earlier discussion on -devel[0]. Is this an intended change to usk +nmuX for all NMUs or should the wording be updated to reflect current behavior? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: SSH keys: DSA vs RSA (was: Alioth and SSH: restored)
On Fri, May 16, 2008 at 11:26 AM, nicolas vigier <[EMAIL PROTECTED]> wrote: > On Thu, 15 May 2008, Steinar H. Gunderson wrote: >> No. Any key who had a single DSA signature created by the flawed version of >> OpenSSL should be considered compromised. DSA requires a secret, random >> number as part of the signature process; if someone figures it out, or you >> use the same number twice, the entire secret key falls. > > If I understand correctly, it means that if you use a good key with a > flawed openssl to connect to an other host using that key, then that > key can be considered compromised. > > But what about using a good key on a host with a good openssl, to > connect to a server which use a bad openssl ? The reason the former fails is because DSA needs a random number to generate its signature (as Steinar describes). This signature is obviously generated with the local openssl. Connecting to a remote host with a bad openssl doesn't matter as the random number is generated with your local good openssl. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Handling of removed packages
On Thu, May 29, 2008 at 02:40:07PM +0200, Kai Wasserbäch wrote: > And for me that is enough, though a automatic notification by > aptitude, when a package is added to that category would be nice. As of version 0.4.11, this does happen. From the NEWS file: * Command-line updates in aptitude will now list packages that are newly obsolete. This doesn't work when a source is removed and all its packages become obsolete, for technical reasons. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Triggers in menu
On Wed, Jun 04, 2008 at 10:06:22PM +0200, Andreas Tille wrote: > On Wed, 4 Jun 2008, Joey Hess wrote: > >> That would prevent update-menus from being run if a package was >> installed not using apt. > > Yes, this is correct. But what is actually the advantage of calling > update-menus using triggers instead of doing it in the postinst. Each package which supplies a menu entry doesn't need a postinst snippet. Only the menu program needs to know what to do. > Currently the > usage of triggers leads rather to more than to less calls of update-menus > while only one is really needed (except I'm missing something). The number of times update-menus is called should be at most as many as before triggers were introduced. Maybe what you're seeing is that packages supplying a menu entry are calling update-menus in their maintainer scripts as well as having the triggered call to update-menus occur. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: bashism question
On Mon, Jun 23, 2008 at 10:07:27AM +0200, Michael Meskes wrote: > With our move to dash as sh we have to remove all bashisms from scripts > run by /bin/sh. However, checkbashism seems to moan about clauses that > work in dash as well. I don't know in which shells a trap with a signal number > is guaranteed to work, but it seems to work well in dash. Policy currently doesn't allow use of XSI extensions which is what "trap -SIGNAL_NAME" is. Therefore, checkbashisms is flagging such use until policy is clarified about this behavior[0]. [0] - http://bugs.debian.org/477240 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: bashism question
On Mon, Jun 23, 2008 at 07:28:36PM +0200, Michael Meskes wrote: > On Mon, Jun 23, 2008 at 05:39:07PM +0100, Adam D. Barratt wrote: > > It's safe for use with dash, but using it is technically a violation of > > Policy (albeit a widespread one). There is a Policy bug open requesting > > that the XSI extensions for trap and kill be permitted (#477240). > > >From this I'd say for Lenny using trap with a signal number is fine. > > Also they same question comes up with the "local" keyword. Dash seems to > support this, while it is not POSIX. The "local" keyword is an explicitly supported extension. These are discussed in Section 10.4 of policy. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))
On Wed, Jun 25, 2008 at 08:49:20PM +0200, Petter Reinholdtsen wrote: > And it would be a lot easier to check spelling in any language if all > programs supported a spell checker that supported any language, and > not only the "simple" ones with a structure similar to English. :) Even better would be programs using a library like enchant which provides a front-end to the myriad other spell libraries. This allows the user/application to use the library backend that works best for their use case/language. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [security] Incorrect file permissions due to (now fixed) perl 5.10 issue
On Thu, Jun 26, 2008 at 11:31:44PM +0200, Norbert Preining wrote: > On Do, 26 Jun 2008, Frans Pop wrote: > > [1]http://lists.debian.org/debian-testing-security-announce/2008/06/msg00016.html > > And exactely that link is not present??? Actually, it is. Even if a typo were present, you could go to threads.html and easily find the post about the perl vulnerability. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: RFC: Idea for improved diversions and alternatives handling
On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote: > What should happen when several packages divert the same file ? > Which one wins ? What about original files, what do they become ? Several packages shouldn't divert the same file, IMO. diversions are useful for specific circumstances and the diverted/diverting packages should be closely related (if not from the source). Alternatives are the better solution when there are myriad, non-conflicting sources which may provide the same file. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: RFC: Idea for improved diversions and alternatives handling
On Fri, Jun 27, 2008 at 07:34:53PM +0100, Ian Jackson wrote:
> James Vega writes ("Re: RFC: Idea for improved diversions and alternatives
> handling"):
> > On Fri, Jun 27, 2008 at 06:40:23PM +0200, Mike Hommey wrote:
> > > What should happen when several packages divert the same file ?
> > > Which one wins ? What about original files, what do they become ?
> >
> > Several packages shouldn't divert the same file, IMO. diversions
> > are useful for specific circumstances and the diverted/diverting
> > packages should be closely related (if not from the source).
> > Alternatives are the better solution when there are myriad,
> > non-conflicting sources which may provide the same file.
>
> That's all very well but what about transitions ?
This would fall under closely related packages. My point was mainly
that diversions need to be thought out and coordinated before being
used as they have more restrictions than alternatives (such as not
supporting multiple packages providing a file that another package
declared a diversion for).
> This all needs some careful thought I think, to make sure we get all
> of the corner cases right.
Agreed. Getting this implemented correctly will be very useful to
those situations where diversions are the right solution.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: RFC: Idea for improved diversions and alternatives handling
On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote: > So if we allow multiple packages to be installed at the same time which > divert the same file, then I think we have another case for wanting to > continue supporting an optional diversion target - or at least for not using > ".diverted" by default, since we wouldn't want diversions from multiple > packages to collide. Maybe ".diverted-$package", then? I don't think this scenario makes sense outside of transitioning a diversion from one package to another. There are two use cases to consider regarding multiple packages and diversions. 1) Multiple packages installing a file that has been diverted. Currently, there is only one "divert to" filename so you'll end up losing data once the second diverted file is installed. This could be alleviated by instead basing the "divert to" filename on the package which contains the file being diverted (as you suggest above). There's still the problem of what to do when the package providing the diversion is uninstalled as now you have conflicting packages. Actually, you already had conflicting packages that just weren't affected yet because of the diversion, which leads to 2). 2) Multiple packages diverting the same file. This currently isn't possible since dpkg-divert will rightly complain about multiple packages trying to divert the same file. If it were to be possible, you would need a layered approach with priorities so there's a defined notion of which package is currently providing the contested file and who would do so when that package is removed. In this case, congratulations, you've reinvented alternatives. So it seems like the solution to both of the above scenarios is the use of alternatives. There is the problem which brian brought up[0] about using diversions when you can't rely on having alternatives setup already but that would be obviated if dpkg internally handled both diversions and alternatives. [0] - [EMAIL PROTECTED] -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: A standard patch rule for our rules
On Wed, Jul 01, 2009 at 07:43:37PM +0200, Andreas Metzler wrote: > Rafael Almeida wrote: > > A ``patch'' rule for debian/rules there should always be > > for I'd like to easily apply patches created by me > > Don't worry I don't think of anything too hard > > a simple standarization will ease my heart > > > Today ``debian/rules build'' is always a good match > > but there's no mandatory ``debian/rules patch'' > > Is the ``build'' rule mandatory? I don't even know > > it seems to work for most packages, though > [...] > > "patch" indeded is the standard way nowadays. See policy 4.9. I think you mean “recommended”, although not using that could be a reason to have a README.source explaining how the package is handled. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Should we improve our (internal) communication?
On Thu, Jul 16, 2009 at 08:16:06PM +0100, Ben Hutchings wrote: > On Thu, 2009-07-16 at 20:25 +0200, Sandro Tosi wrote: > > Hi all, > > today ries (aka ftp-master) was down due to a scheduled maintenance > > activity. > > > > Now, scheduled means programmed, and suddenly this question comes to > > me: should the project be notified of such core activities? should we > > only relay on #debian-devel irc channel topic to know this? > [...] > > This is what debian-infrastructure-announce is for (though > debian-devel-announce might be appropriate in some cases). But there > was no announcement in this case. Which Sandro mentioned in his email. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: piuparts run by every uploader
On Tue, Jul 21, 2009 at 11:44:07AM -0400, Jonathan Yu wrote: > Better yet, if we could periodically run it on all of the modules in > our SVN repository (pkg-perl) and display the logs, then it would give > us a nice to-do list of things to look at. http://piuparts.debian.org/sid/maintainer/p/pkg-perl-maintain...@lists.alioth.debian.org.html -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: piuparts run by every uploader
On Tue, Jul 21, 2009 at 02:08:26PM -0400, Jonathan Yu wrote: > Hi James: > > On Tue, Jul 21, 2009 at 12:11 PM, James Vega wrote: > > On Tue, Jul 21, 2009 at 11:44:07AM -0400, Jonathan Yu wrote: > >> Better yet, if we could periodically run it on all of the modules in > >> our SVN repository (pkg-perl) and display the logs, then it would give > >> us a nice to-do list of things to look at. > > > > http://piuparts.debian.org/sid/maintainer/p/pkg-perl-maintain...@lists.alioth.debian.org.html > > Thanks, that link looks neat & should be quite useful for our group. > > One thing that puzzles me right now is all the unknowns, and it's > flagging a bunch of things as: "circular dependency: N/A" -- is anyone > else having this issue, and if so, what does it mean? Q. What does a depends of ''circular dependency'' mean? A) perl depends on perl-modules and perl-modules depends on perl. That's an easy one. The more annoying ones are those from different source packages. http://wiki.debian.org/piuparts/FAQ -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
RFC: Providing vi when /usr isn't mounted
tag 528494 help thanks #528494 raised the idea of having vim-tiny (the default vi-like editor on a base install) provide /bin/vi so that it would be accessible in situations where /usr isn't available. At first glance, I naïvely figured this would be an easy change. Of course, this wasn't the case so I'd like to get some feedback on the proper approach for this since this use case is actually something I've intended on doing since vim-tiny became Priority: important. We currently have 8 source packages[0] building binary packages which provide vi in some form. All except elvis-tiny use the alternatives system to provide /usr/bin/vi. Elvis-tiny ships /bin/vi which is a small binary implementing its own sort of alternatives functionality[1]. The problem here is that I can't simply have vim-tiny ship /bin/vi partly due to elvis-tiny but primarily due to the alternatives system rightly not supporting a provided alternative changing location depending on which of the available alternatives is active. This would require a separate alternative, which is sub-optimal because it leaves the possibility for different behavior depending on the order of the system directories in the user's $PATH, as well as a naming conflict if /usr/bin is symlinked to /bin. Having vim-tiny simply ship /bin/vi and not use the alternatives system runs into similar problems. Thoughts? Suggestions? [0] - Felipe Augusto van de Wiel (faw) levee Debian Vim Maintainers vim Pierre Habouzit vim (U) Teruyuki Morimura jvim Jan Christoph Nordholz nvi Brendan O'Dea vile (U) Miquel van Smoornburg elvis-tiny Paul van Tilburg vile James Vega vim (U) Colin Watson vigor Paweł Więcek e3 [1] - See debian/wrapper.c at <http://patch-tracker.debian.org/patch/debianonly/view/elvis-tiny/1.4-22> -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: RFC: Providing vi when /usr isn't mounted
On Thu, Sep 10, 2009 at 09:19:25AM +0200, Miquel van Smoorenburg wrote: > On Wed, 2009-09-09 at 19:02 -0400, James Vega wrote: > > tag 528494 help > > thanks > > > > #528494 raised the idea of having vim-tiny (the default vi-like editor > > on a base install) provide /bin/vi so that it would be accessible in > > situations where /usr isn't available. At first glance, I naïvely > > figured this would be an easy change. Of course, this wasn't the case > > so I'd like to get some feedback on the proper approach for this since > > this use case is actually something I've intended on doing since > > vim-tiny became Priority: important. > > > > We currently have 8 source packages[0] building binary packages which > > provide vi in some form. All except elvis-tiny use the alternatives > > system to provide /usr/bin/vi. Elvis-tiny ships /bin/vi which is a > > small binary implementing its own sort of alternatives functionality[1]. > > > > The problem here is that I can't simply have vim-tiny ship /bin/vi > > partly due to elvis-tiny but primarily due to the alternatives system > > rightly not supporting a provided alternative changing location > > depending on which of the available alternatives is active. > > [I sent this as a reply to bug #528494, but forgot to add Cc's, so > here it is again] > > Well, the original bug submission #528494 talks about that- you > cannot have different 'vi' binaries in /bin and /usr/bin, since > that would be very inconsistent. It's not purely about inconsistency. There's also the issue of having binaries installed in the /usr/bin and /bin with the same name. This prevents /usr/bin from being a symlink to /bin. How important that consideration is, I'm not sure. > What /bin/vi in elvis-tiny does is very simple: > > - if /usr/bin/vi exists, execute it (common case) > - else if /bin/elvis-tiny exists execute it (/usr not available) > - else print error and exit > > This way you always get /usr/bin/vi, even if /bin is in your > PATH first, unless /usr/bin/vi doesn't exist. > > We could work together to allow multiple '*vi-tiny' packages to > be installed, in that case we should really do the following: > > - each *vi-tiny package sets an alternative for /bin/vi-tiny > - each *vi-tiny package depends on vi-tiny-common > - vi-tiny-common is basically the /bin/vi from elvis-tiny, > as described above, where it tries to execute /bin/vi-tiny > instead of /bin/elvis-tiny A similar suggestion was made when on IRC. The difference being that /bin/vi checked for /usr/bin/vi.usr.bin and /bin/vi.bin in order to avoid the potential name collision. > However, to me this sounds as a lot of work for very little > gain. We already have the elvis-tiny package to provide a small > vi clone for situations where /usr is not available. This > would be a rescue situation. Is it really neccesary to be > able to choose between tons of vi-clones in that case ? The idea isn't to make people choose among tons of vi-clones any more than we “make” them decide among the various other alternatives that Debian's packages provide. The idea is to have the vi-clone that ships by default with Debian be available without /usr and to do so without preventing other vi-clones from being able to do the same thing. If the sysadmin chooses to install multiple vi-clones which provide a binary under /bin, they'll have the ability to choose which one should be used by default. Just like any other program that makes use of the alternatives system. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: opposition against clamav-data in debian volatile
On Mon, Sep 21, 2009 at 11:49 AM, Henrique de Moraes Holschuh wrote: > On Mon, 21 Sep 2009, Marc Haber wrote: >> And people know that the package is built automatically. All users I >> know especially opted in to using the package instead of freshclam for >> some-or-other reason. > > WHERE is that information published? > > I don't see it in the package description, and I don't see it in > volatile.d.o either. It is not even in the for-developers page. >From the description of the volatile package: This package contains data files for clamav and was automatically generated by clamav-getfiles from the identically named package. ... Please note that this package was built automatically without human supervision and was only automatically checked before upload. Use at your own risk. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lintian error weak-library-dev-dependency
On Thu, Sep 24, 2009 at 11:33 AM, Norbert Preining wrote: > Now we have > libkpathsea-dev depends libkpathsea4 (= 2007.dfsg.2-7) > and I still get these errors. libkpathsea-dev is at version 2007.dfsg.2-7. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547773 Fixed in Lintian 2.2.17 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fields used in packages
On Fri, Sep 25, 2009 at 2:55 PM, George Danchev wrote: > I've recently done a little survey about the fields used in our control files > (*_Release files excluded). Currently there are ~80 different fields [1] used > in > testing and unstable, which basically fall into these groups: > > 1) listed in debian policy and accompanied sub-policies (like Python-*). > 2) handled by dpkg (wanna-build/buildds/dak/other?), but not mentioned in > policy or sub-policies (like Vcs-*) At least for Vcs-*, that's documented in devref: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-vcs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550860: ITP: gnaughty -- downloader for adult content
On Wed, Oct 14, 2009 at 4:43 PM, Michael Gilbert wrote: > On Wed, 14 Oct 2009 22:27:25 +0200, Yves-Alexis Perez wrote: >> On mer, 2009-10-14 at 16:23 -0400, Michael Gilbert wrote: >> > the key litmus test is: does the application depend solely on non-free >> > information to function properly. these google applications fail >> > this test because the licensing of the data itself is at the user's >> > discretion. hence, they are permitted in main. >> >> I don't really think clive use data licensed at the user discretion. > > i agree, clive only functions properly when it has access to the > non-free content on youtube, so it would pass my litmus test, and should > be moved to contrib. What makes youtube content (or any of the media content from the many other sites clive supports) automatically non-free? Doesn't it depend on how the media's author has decided to license their work? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: perl and perl-modules; reflexive dependencies vs. archive bloat
On Fri, Oct 23, 2009 at 03:22:34PM -0700, Don Armstrong wrote: > On Sat, 24 Oct 2009, Josselin Mouette wrote: > > Le vendredi 23 octobre 2009 à 14:25 -0700, Don Armstrong a écrit : > > > 3: Specifically, where Package A Depends on (B=1), and Package B > > > Depends on A; A and B are from the same source, B is architecture > > > independent, and does not require configuration. > > > > In the general case, B doesn’t need to depend on A. So this is not a > > problem for that many packages. > > Generally speaking, A tends to be necessary for B "to provide a > significant amount of functionality". > > However, I agree that in almost all cases (including this case) it > seems silly for any other package to depend on B or for users to > install B directly. I actually suggested that perl-modules recommend > perl, but that was rejected for the reason that perl-modules doesn't > do anything useful without perl. I don't see how perl-modules is that much different than the various arch-independent data packages which provide little to no functionality on their own but are required by another arch-dependent package. Many of those either Recommend the relevant package or declare no relationship at all. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Switch on compiler hardening defaults
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > Arguments against: > - makes the compiler's behavior different than stock compiler. > Rebuttal: honestly, I don't care -- it seems like such a > huge win for safety and is easy to debug. Debian > already carries plenty of patches anyway -- there > is no such thing as the "stock compiler". > - makes more work for dealing with warnings. > Rebuttal: those warnings are there for a reason -- they can > be real security issues, and should be fixed. > - lacks documentation. > Rebuttal: that may have been true a while ago, but I've worked > hard to document the features and how to handle > problems. See [2]. Even the gcc man pages are patched. > - makes running Debian slower. > Rebuttal: no, nothing supports this. The bulk of _FORTIFY_SOURCE > is compile-time. Run-time checks, including those from > -fstack-protector are just not measurable. The burden of > evidence for anyone claiming this is on them. I'm not > suggesting we turn on PIE; that option can be a problem. - breaks debugging with gdb. See <1256300822.13273.39.ca...@fsopti579.f-secure.com> on this list and #346409. You provided a patch for #346409, but there appears to be issues with it as noted in the bug log. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: ReBuild-Depends?
On Thu, Oct 29, 2009 at 11:33 AM, Dmitry E. Oboukhov wrote: > Could we add 'ReBuild-Depends' statement into debian/control to > rebuild like packages when depends rebuild? But such kind of depends > require some changes in buildd system. This is only needed when the dependencies change something that would require a rebuild, not necessarily every time they're updated. We have a process to handle that -- binNMUs. http://wiki.debian.org/binNMU -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dep3 nit-picks
On Thu, Nov 5, 2009 at 4:44 PM, Raphael Hertzog wrote: > [ moving to -devel from a private discussion to have more feedback ] > > Daniel was asking me how several unstructured paragraphs are supposed to > be treated for the Description field. I told him that the description is > the concatenation of all of them. Do other people agree with Daniel that > the points that he raises need clarifications? > > DEP URL for reference: http://dep.debian.net/deps/dep3/ > > On Thu, 05 Nov 2009, Daniel Kahn Gillmor wrote: >> On 11/05/2009 02:45 AM, Raphaël Hertzog wrote: >> 4) Reviewed-By is semantically unclear. I can review something and >> decide it's a bad idea. In that case, it has been reviewed by dkg, but >> would it really be Reviewed-By: dkg? probably not (i'm assuming there's >> considered to be no semantic difference between Reviewed-By and >> Acked-By). Workflows can differentiate between Reviewed-By and Acked-By, but that's not necessary (e.g., Reviewed-By indicates a positive review, Acked-By indicates approval to commit). >> I'm not suggesting that we change the header label >> necessarily (and i don't know why it was changed from Signed-off-by to >> Reviewed-by in the first place -- can you point me to any discussion >> about that change?), http://article.gmane.org/gmane.linux.debian.devel.general/141581 >> but if "Reviewed-By" is going to have any sort of >> "stamp of approval" connotation, it should be explicitly noted someplace. > > It has an implicit meaning of approval yes. If the review was negative, it > should not be added or it should be clarified in the Description what the > reviewer's comments were (always a good idea). Right. I'd think that if there were a negative review, the proposer of the patch would go back to work on it further before resubmitting. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Iceweasel and Firefox compatibility
On Mon, Nov 9, 2009 at 11:12 AM, John Goerzen wrote: > It would be *great* if this could be fixed before sarge comes out. Sarge shipped with firefox, so no worries there. ;) Squeeze, on the other hand, might need some work. SCNR. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SoundJuicer Package Adoption
On Thu, Nov 12, 2009 at 4:21 PM, Barry deFreese wrote: > Andreas Marschke wrote: >> I've recently seen that there are problems with SoundJuicer and open for >> adoption maybe. > > Where did you see that it was up for adoption? It's not listed as Orphaned or > RFA'd? In fact it just had an upload on 10/31. I'd guess that was a misinterpretation of Ross Burton's idle request for someone to adopt it upstream. http://www.burtonini.com/blog/computers/postr/new-maintainer-2009-11-12-10-49 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Nov 24, 2009 at 10:45 AM, Manoj Srivastava wrote: > On Tue, Nov 24 2009, Stefano Zacchiroli wrote: > >> On Mon, Nov 23, 2009 at 09:02:05PM +, Philipp Kern wrote: >>> Everybody should pipe his uploads through lintian. That's nothing >>> that should be in the upload tool, IMHO. A unixy tool does one job, >>> not two. >> >> Counter example: everybody should pipe his .changes through >> debchange. > > Umm, what? I thought dch was something used to create or modify > ./debian/changelog file. Pretty sure zack meant debsign, given some extra context that got snipped, "Still the check for unsigned .changes is in dput and it's pretty damn useful." -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Has Debian abandoned Python?
On Thu, Dec 3, 2009 at 4:16 PM, Joey Hess wrote: > Frans Pop wrote: >> I think it *is* material in this instance: >> >> Versions of python-defaults in Debian: >> unstable: 2.5.4-2 >> experimental: 2.5.4-3 >> >> Version of package in Ubuntu: >> Version: 2.6.4-0ubuntu1 (karmic) >> Uploaded by: Matthias Klose >> On date: 2009-10-30 12:05:08 UTC >> >> That is over *two months* ago. >> >> Version: 2.6.2-0ubuntu1 (jaunty) >> Apparently uploaded *33 weeks* ago. > > Perhaps more germane to the head of this thread is that python3.0 is not > in Debian, but prereleases were added to Ubuntu apparently in 2007. The python3.1 package has been in experimental since March of this year. I'm not positive, but I don't think python3.0 was ever uploaded to Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dh_config_model_upgrade: package upgrade with Config::Model
On Thu, Dec 17, 2009 at 8:24 AM, Dominique Dumont wrote: > On Wednesday 16 December 2009 17:40:55 Neil Williams wrote: >> No. The package should simply exit cleanly with a successful return >> value if perl does not exist, letting everything else proceed as before. >> The postinst itself needs to check - that way, Emdebian doesn't have to >> patch every package using dh_config_model. > > Ok. Here's the new postinst snippet injected by dh_config_model_upgrade: > > # In case of error (error in configuration file or model bug), the > # configuration file is left as is. > > # testing perl is required to avoid problem in embedded environments > if [[ -e /usr/bin/perl ]] '[[' for testing is a bashism. This should be if [ -e /usr/bin/perl ] or more accurately if [ -x /usr/bin/perl ] -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: QA pages and epochs: problem?
Julien is correct. See #559863 and merged bugs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545782: imagemagick-dbg: missing README.Debian to explain how programs are used
On Mon, Dec 28, 2009 at 11:09:34AM +0200, Jari Aalto wrote: > "Nelson A. de Oliveira" writes: > >> README.Debian to explain how programs are used". Please provide > > > > The problem here is that we have a lot of -dbg packages on Debian > > Do we need the same README file on all of them? > > > > ...the package maintainer is responsible in helping the user to get a > > backtrace ... Or at least an explanation in the gdb package only. > > Neil Williams writes: > > > Once the -dbg packages are installed: > > $ gdb /usr/bin/convert > > > > The rest is down to the gdb manpage, no? > > > > gdb does all the work of locating /usr/lib/debug/usr/bin/convert, hence > > all such files are mode 0644. > > > > That is down to the gdb manpage, not every single -dbg package in the > > entire archive IMHO. There are other sources of info too, like the Wiki. > > > > http://wiki.debian.org/HowToGetABacktrace > > In latest lintian, a message was added that warned about missing > > debian/REAADME.source > > in order to document the used patch system (dpatch, quilt etc.). It is for documenting more than just the patch system. Refer to policy's description[0] for the full details. > It > could have been be argued that this information were already available > in the manual pages. It has, which is why the README.source is supposed to refer back to the patch system's documentation instead of duplicating it. [0] - http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
On Sun, Jul 06, 2008 at 01:08:40PM -0400, Joey Hess wrote: > Josselin Mouette wrote: > > Therefore, I still feel that, despite it being a big mess, the current > > situation is the best: > > * the default menu contains only what is needed, and we are still > > hunting down entries that are useless to make them not show up > > by default; > > * users wanting the Debian menu and its gazillions of entries > > including window managers, terminal emulators and shell > > interpreters can enable it easily in the menu editor; > > * those really wanting only the Debian menu can replace > > gnome-applications.menu by debian-menu.menu. > > > > If you want this to change, you need to seriously think about evolutions > > to both XDG and Debian menu systems, to convince fd.o and the Debian > > menu maintainer to implement them > > Actually, no, if you want this to change, you have only to do nothing. > > People (many of them MOTUs from Ubuntu in my experience) are filing lots of > requestes for random packages to have .desktop files added to them, so > they appear in the gnome menu. The criteria seems to be "a program that > $RANDOM_USER would like to have on the menu and files a bug about || > that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason". I wouldn't be surprised if most of those had "NoDisplay=true" as one of the fields[0]. While there may be a drive to add .desktop files to packaging, there's a similar (sometimes overzealous, IME) drive to have them not displayed by default. [0] - https://wiki.ubuntu.com/UbuntuPackagingChanges?highlight=%28NoDisplay%29#head-5c07e3429829189474d24f6bcc1f2bee2f385e9a -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Kernel 2.6.25 broke iPod support for me, but who to bug?
On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> Hi.
>
> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.
>
> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!")
Are you sure this is a kernel change and not just a change in your
kernel config? I brought up what seems to be the same (or at least
closely related) problem 4 years ago on lkml[0].
[0] - http://lkml.org/lkml/2004/4/5/209
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Re: Good communication with upstream is good idea
On Mon, Jul 21, 2008 at 09:38:01AM -0700, John H. Robinson, IV wrote: > What is the problem with closing the Debian bugs in the Debian > changelog, and letting the Ubuntu MOTU (I hope I am using the right > terminology here) handle the Ubuntu bug tracking? No one is saying that Debian developers *have* to close Ubuntu bugs. Steve was just describing that it is possible for Debian developers to address Ubuntu bugs if they choose to. Just like some upstream authors may reference Debian bugs when they fix problems, Debian (as upstream for Ubuntu) can do the same. Choose as much or as little involvement as you like. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: "glib too old" OR "Lenny broken by default?"
On Thu, Jul 24, 2008 at 01:31:52AM +0300, Eddy Petrișor wrote: > During a regular upgrade of my laptop (follows lenny) I have seen these > messages: Looks like the same issue discussed earlier in the week. http://lists.debian.org/debian-devel/2008/07/msg00643.html -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Screenshots of GUI applications (again)
On Fri, Jul 25, 2008 at 02:40:20PM +0100, Jon Dowland wrote: > On Tue, Jul 22, 2008 at 05:05:03PM +0200, Christoph Haas wrote: > > the matter has been discussed at least twice already. Roberto C. Sanchez > > brought the matter back up in January 2008. > > On d-d? I can't find that thread in the list archives... <[EMAIL PROTECTED]> and <[EMAIL PROTECTED]> were the two previous discussions. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: packages up for adoption
On Wed, Aug 27, 2008 at 06:38:03PM +0100, James Troup wrote: > These 3 are still up for adoption: > > > * gnus > > * gimp-dimage-color > > * xloadimage Is there any reason to keep xloadimage around? From what I can tell, xli is a fork of it that saw some more development but both seem to be dead in the water. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: List of RC-buggy source packages by maintainer/uploader
On Mon, Oct 06, 2008 at 09:28:51PM +0200, Lucas Nussbaum wrote: > James Vega <[EMAIL PROTECTED]> >vim (U) Working on a tpu upload to fix issues for Lenny. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Correct way to move /etc config files
On Tue, Oct 21, 2008 at 07:32:48PM -0700, Steve Langasek wrote: > On Wed, Oct 22, 2008 at 01:00:34AM +0200, Luca Capello wrote: > > Hi there! > > > This mail originates from the discussion at [1]: simply, I need to move > > an /etc file (/etc/frameworkd.conf) from one package (fso-frameworkd) to > > another one (fso-config-gta02). > > > However, I don't really know the best way to manage this situation and I > > cannot find any reference on the Debian Developer's Reference [2] nor on > > the Debian Policy [3] nor the Debian wiki [4]. > > Use Replaces:, just as for other files that move between packages. As I understand it, you should also remove the conffile[0] from the original package according. If you do not, you'll run into bugs like #499451. [0] - http://wiki.debian.org/DpkgConffileHandling -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: volunteers wanted for driving/finalizing a DEP on debian/copyright format
On Tue, Dec 02, 2008 at 09:51:04PM +0100, Miriam Ruiz wrote: > 2008/12/2 Stefano Zacchiroli <[EMAIL PROTECTED]>: > > [ M-F-T set to -devel ] > > > > On Tue, Dec 02, 2008 at 07:30:54PM +0100, Miriam Ruiz wrote: > >> We should somehow tag those conflictive licenses with debtags, so that > >> users can filter out the ones they don't wont easily. I don't object > > > > Except that debtags are right now for binary packages, whereas > > copyright is for source packages. > > > > Moreover, copyright is something already coded (and correctly "fixed") > > in debian/copyright. > > > > The solution to your problem already exists (actually, it has been > > *designed* for that): http://wiki.debian.org/Proposals/CopyrightFormat > > , it "just" needs someone with the energy of finalizing the proposal > > (most likely via a DEP), so that is stops being an ever changing wiki > > page. > > Well, not exactly, you cannot easily see the copyright file before > installing the package, can you? It's linked from the packages.d.o and PTS page for the package. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Packages still depending on GTK+ 1.2
On Fri, Dec 05, 2008 at 07:06:26PM +0100, Josselin Mouette wrote: > Jon Bernard <[EMAIL PROTECTED]> >e16menuedit > => we don’t ship E16 anymore packages.debian.org says otherwise. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Problem with bts2ldap and therefore bts.turmzimmer.net ?
On Thu, Dec 11, 2008 at 07:53:23PM +0100, Olivier Berger wrote: > While we're at it, I find mentions of > http://people.debian.org/~aba/bts2ldap/ sometimes by googleing > bts2ldap... but it's not there ATM. I'm just curious, investingating all > sorts of bug-related things in Debian, not really missing it for a > specific need. Looks like that wasn't moved to ravel when people.debian.org changed hosts. It's still accessible, for now, if you use oldpeople.d.o instead. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Bug#508644: general: installing mdadm pulls in citadel-server as depedency
On Sat, Dec 13, 2008 at 06:35:20PM +0100, Daniel Baumann wrote: > Hasse Hagen Johansen wrote: > > I just would let you know that maybe it is a more general problem as mdadm > > is also pulling citadel-server in as a dependency > > this really sucks (in this case only if you have recommends enabled, > though). someone should check all depends and recommends in debian to > not declare unconditional relations to mail-transfer-agent. Lars Bahner pyca Ben Collins sxid Debian mdadm maintainers mdadm Mario Joussen mdadm (U) martin f. krafft mdadm (U) Gerrit Pape bcron raccess4vbox3 KELEMEN Péter arpwatch Nick Rusnov nmh Santiago Vila smartlist -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: percentage of popcon submitters
On Thu, Jan 15, 2009 at 4:55 PM, markus schnalke wrote: > [2009-01-15 22:37] Michael Goetze >> >> before wild speculations ensues, you might want to specify what you >> really want to know: the percentage of people installing debian systems >> who use popcon (always/sometimes), or the percentage of installed >> machines that submit popcon data? > > Seems my wording was unclear. > > I want to know the percentage of installed machines that submit popcon > data. That requires knowing the number of computers that have Debian installed which, as has been discussed various times in the past on this list, is difficult to determine. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Pbuilder loads a lot of texlive fonts
On Wed, Nov 07, 2007 at 04:12:57PM +0100, Andreas Tille wrote: > I would like to stop this overkill because it is a pure waste of > bandwidth but I have not even an idea why this happens, because > I do not find these packages in the list of Recommens. Did I > missed something? I noticed this as well and sent a mail about it to the Tex list[0] but Riku's blog post[1] was a good hint. After turning off automatic installation of Recommends, the packages are no longer installed. I didn't take the time to look into what was Recommending the packages, though. James [0] - http://lists.debian.org/debian-tex-maint/2007/11/msg6.html [1] - http://nchip.livejournal.com/11175.html -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
Mitchell <[EMAIL PROTECTED]> opensync-plugin-palm-dev (U) David Martínez Moreno <[EMAIL PROTECTED]> etl-dev (U) Josselin Mouette <[EMAIL PROTECTED]> system-tools-backends-dev (U) David Nusinow <[EMAIL PROTECTED]> libdiscover1-pic (U) Nelson A. de Oliveira <[EMAIL PROTECTED]> biosquid-dev Nelson A. de Oliveira <[EMAIL PROTECTED]> libajax5-dev (U) libnucleus5-dev (U) Masahito Omote <[EMAIL PROTECTED]> libuim-data Patrick Ouellette <[EMAIL PROTECTED]> opt Sam Hocevar (Debian packages) <[EMAIL PROTECTED]> libdts-dev (U) libdvb-dev (U) liblivemedia-dev (U) Goedson Teixeira Paixao <[EMAIL PROTECTED]> libgfccore-doc Gerrit Pape <[EMAIL PROTECTED]> cvm-dev dietlibc dietlibc-dev fgetty fnord integrit runit skalibs-dev Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]> clips-common Yves-Alexis Perez <[EMAIL PROTECTED]> xfce4-dev-tools (U) Thomas Perl <[EMAIL PROTECTED]> libflake-dev (U) Charles Plessy <[EMAIL PROTECTED]> libajax5-dev (U) libnucleus5-dev (U) Gregory Pomerantz <[EMAIL PROTECTED]> libxkbsel-dev Frans Pop <[EMAIL PROTECTED]> debian-installer (U) os-prober (U) Norbert Preining <[EMAIL PROTECTED]> texlive-base-bin-doc (U) texlive-metapost-doc (U) Christophe Prud'homme <[EMAIL PROTECTED]> libnetgen-dev (U) Mark Purcell <[EMAIL PROTECTED]> libicecc-dev (U) Petter Reinholdtsen <[EMAIL PROTECTED]> libdiscover1-pic (U) Steve M. Robbins <[EMAIL PROTECTED]> libgeomview-dev Emanuele Rocca <[EMAIL PROTECTED]> xfce4-dev-tools (U) José L. Redrejo Rodríguez <[EMAIL PROTECTED]> gambas-doc gambas2-doc Herve Rousseau <[EMAIL PROTECTED]> minit Anibal Monsalve Salazar <[EMAIL PROTECTED]> libgii1-target-x liblpsolve55-dev (U) Otavio Salvador <[EMAIL PROTECTED]> libdiscover1-pic (U) system-tools-backends-dev (U) Taketoshi Sano <[EMAIL PROTECTED]> extipl-boot Niv Sardi <[EMAIL PROTECTED]> system-tools-backends-dev (U) David Schleef <[EMAIL PROTECTED]> libuclibc0 Thomas Schmidt <[EMAIL PROTECTED]> libmdsp-dev (U) Andreas Schuldei <[EMAIL PROTECTED]> libcurl3-dbg (U) Martin Schulze <[EMAIL PROTECTED]> cgilib Frederik Schüler <[EMAIL PROTECTED]> linux-headers-2.6.23-1-common (U) linux-headers-2.6.23-1-common-xen (U) linux-libc-dev (U) Gürkan Sengün <[EMAIL PROTECTED]> libfreebasic Jamey Sharp <[EMAIL PROTECTED]> libpthread-stubs0 (U) Sjoerd Simons <[EMAIL PROTECTED]> libavahi-common-data (U) libpulse-browse0-dbg (U) Marc Singer <[EMAIL PROTECTED]> bsign Jonas Smedegaard <[EMAIL PROTECTED]> libsrtp1-dev (U) Jose Carlos Garcia Sogo <[EMAIL PROTECTED]> system-tools-backends-dev Joop Stakenborg <[EMAIL PROTECTED]> libhamlib-doc libhamlib-doc (U) Gaudenz Steinlin <[EMAIL PROTECTED]> libdiscover1-pic (U) Al Stone <[EMAIL PROTECTED]> libacovea-dev libatomic-ops-dev (U) llvm-libs Michael Stone <[EMAIL PROTECTED]> libopie-dev Ondřej Surý <[EMAIL PROTECTED]> libldns-dev NOKUBI Takatsugu <[EMAIL PROTECTED]> chasen-cannadic Reinhard Tartler <[EMAIL PROTECTED]> xine-dbg Debian GSS Team <[EMAIL PROTECTED]> libgss-dbg Debian Shishi Team <[EMAIL PROTECTED]> shishi-dbg Paul van Tilburg <[EMAIL PROTECTED]> libdaemons-ruby1.8 (U) Marcela Tiznado <[EMAIL PROTECTED]> when Juan Esteban Monsalve Tobon <[EMAIL PROTECTED]> libgii1-target-x (U) liblpsolve55-dev Gerhard Tonn <[EMAIL PROTECTED]> gcc-3.3-base (U) gcc-3.4-base (U) Josh Triplett <[EMAIL PROTECTED]> libpthread-stubs0 (U) Theodore Y. Ts'o <[EMAIL PROTECTED]> e2fsck-static Utopia Maintenance Team <[EMAIL PROTECTED]> libavahi-common-data Arnaud Vandyck <[EMAIL PROTECTED]> libantlr-dev (U) Andrea Veri <[EMAIL PROTECTED]> libagg-dev Sune Vuorela <[EMAIL PROTECTED]> libqt3-headers (U) mga-vid-source Neal H. Walfield <[EMAIL PROTECTED]> gnumach (U) gnumach-dev (U) Colin Watson <[EMAIL PROTECTED]> os-prober (U) Torsten Werner <[EMAIL PROTECTED]> libmrss0-dbg (U) libnxml0-dbg (U) paintlib2c2a-dbg (U) Ian Wienand <[EMAIL PROTECTED]> libatomic-ops-dev Patrick Winnertz <[EMAIL PROTECTED]> libitalc Alexander Wirt <[EMAIL PROTECTED]> iproute-dev iproute-doc Paul Wise <[EMAIL PROTECTED]> etl-dev (U) Paweł Więcek <[EMAIL PROTECTED]> e3 Enrico Zini <[EMAIL PROTECTED]> dballe-common libcnf-dev libdballe-bufrex-doc libdballe-core-doc libdballe-db-doc libdballe-msg-doc -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: List of packages which should probably be Architecture: all
On Wed, Jan 02, 2008 at 10:18:46PM +0100, Michael Biebl wrote: > So, what's the proper solution to that? Cluttering the archive with a > load of -dbg packages or leave it as is? The solution I took for the Vim packages was to have ORed Depends on all of the binary packages that the -dbg package contains debugging symbols for. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: desktop-command-not-in-package: link to an arch-dependent package in a arch-independent package
On Sun, Jan 10, 2010 at 03:47:39PM +0100, Xavier Roche wrote: > Ralf Treinen a écrit : > >True, but this is really an exceptional case. I suspect the normal case is > >that one installs both packages. > > Yep, exactly. OTOH, I will just move the small desktop file in the > arch-dependent one, which is going to spoil some additional bytes, > but nothing too serious fortunately :) > > The only consequence is a typical conflict when installing the new > package because a file was moved from a package to another one, with > dependency issues (something I already experienced): One uses Replaces to indicate that there is a file conflict. > installed:package A > installed:package B contains > new:package A [new version] contains > new:package B [new version] > > Typicall update step when updating A: > - A depends on B, will update B later > - remove A > - installing new A, but already exist > ==> FAIL Package: A Depends: B Conflicts: B (<< newversion) Replaces: B (<< newversion) -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: iceweasel and facebook photos
On Fri, Jan 15, 2010 at 10:15 AM, Norbert Preining wrote: > Hi everyone, > > I know that is not the bug forum for iceweasel, I still ask here. > > I *know* for sure that some time ago Iceweasel was able to use the > normal Java based facebook photo upload interface. Are you being affected by Java's brokenness with bindv6only (c.f., http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560056)? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Uploads without the architecture-dependant binary packages.
On Tue, Jan 26, 2010 at 08:14:14AM +0100, Goswin von Brederlow wrote: > Mike Hommey writes: > > > On Mon, Jan 25, 2010 at 06:24:49PM +0100, Goswin von Brederlow wrote: > >> That has always been a feature but recently the DAK has changed to throw > >> away the maintainer build debs (while still requireing them to be > >> uploaded) and running an autobuild on all archs. > > > > No it hasn't changed, yet. > > > > Mike > > Still not? damn. It was presented in > > http://lists.debian.org/debian-devel-announce/2009/11/msg1.html > > | The current "winning" opinion is to go with the source+throw away > | binaries route. We are close to being able to achieve this, it is > | simply that it has not yet been enabled. Before any version of this > | can be enabled, buildd autosigning needs to be implemented in order > | that dak can differentiate buildd uploads vs maintainer uploads. > > and later argued that it would suffice to throw away debs in source > uploads and allow all binary only uploads (from buildds or porters > doesn't really matter). Looks like ftp-master didn't take to that. Or they're waiting for other items to be implemented before moving forward, just like the text you quoted says. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Bits from the Mozilla Extension Packaging Team
On Mon, Feb 1, 2010 at 3:34 PM, Thilo Six wrote: > Benjamin Drung wrote the following on 01.02.2010 20:34 >> icedove-quotecolors > > 2nd question: > In the good old days (when ever these were) someone like a short sighted > person like me could search via apt or aptitude for *compatible* extentions > to his application. > Now does it mean, that all those xulrunner based apps can make use the same > extensions? > e.g. does ist make sens to use "xul-ext-quotecolors" with iceweasle? It does make sense to use xul-ext-quotecolors with iceape, even though the current package forces icedove usage. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: git and quilt
On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote: > I receive the following error from lintian and am looking for some > guidance/best practices. > > % lintian --pedantic cdpr_2.3-3.dsc > P: cdpr source: direct-changes-in-diff-but-no-patch-system Makefile and > 1 more This isn't an error. It's an informational message only shown in pedantic mode. From lintian(1): “Pedantic tags are Lintian at its most pickiest and include checks for particular Debian packaging styles and checks that many people disagree with. Expect false positives and Lintian tags that you don't consider useful if you use this option.” In other words, if you think the tag is useful then fix it, otherwise ignore it. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: md5sums files
On Thu, Mar 04, 2010 at 02:11:55AM +0100, Harald Braumann wrote: > I think I was finally able to decipher your message. But my other points > still > hold. And while it is just a matter of programming, simple or not, it already > exists in debhelper. So doing it at build time is SMOAOLTDR, by which I mean > "simply a matter of adding one line to debian/rules". You make the mistake of assuming everyone use debhelper. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Submitting bugs for manpage improvements
On Sun, Mar 7, 2010 at 9:53 AM, Frank Lin PIAT wrote: > Dear devscripts maintainers, > > On Tue, 2009-10-20 at 07:17 +0200, Frank Lin PIAT wrote: >> >> I have written a small script to make it easy to submit manpage >> improvements (it's attached). >> I believe that it much more effective to submit a patch, rather than >> explaining what needs to be improved. The tool works like quilt, dpatch >> & co. One would just invoke: >> >> % man-reportbug chfn > > Are you interested in shipping this tool in devscripts? > (Let me know if you aren't, I would consider an alternative way to ship > it). It definitely looks like a useful tool to have somewhere. I'm interested in what the reportbug people (Cced) think about integrating the functionality, as you suggested in your initial request. In the mean time, I can add it to my list of things to look at when I next have some time to work on devscripts. I'm hoping to get some soon, but things have been a bit hectic lately. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/14ccba101003181232y148de9a6vcb405d6c0eae7...@mail.gmail.com
Re: About new source formats for packages without patches
On Wed, Mar 31, 2010 at 08:47:28PM +0900, Osamu Aoki wrote: > Hi, > > On Wed, Mar 31, 2010 at 11:18:30AM +0200, Raphael Hertzog wrote: > > On Wed, 31 Mar 2010, Niels Thykier wrote: > > > That being said, I would (as it is now) actually prefer that it was > > > just a helper tool that from a VCS could derive a source package of > > > existing format. That would probably also increase the adoption rate, > > > since existing tools would work with those formats. > > > > The (theoretical) format that I gave as example was precisely this: it > > generates a "3.0 (quilt)" source package using a VCS repository as input. > > I guess what we should have is additional line in it or additional file > to record vcs used for packaging which will not interface with the basic > operation of other tools. You mean Vcs-* in debian/control? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: How does lintian detect embedded-zlib?
On Tue, Apr 13, 2010 at 10:22:55PM +0200, Matthias Klumpp wrote:
> Hello!
> Cause binaries generated by the FPC (FreePascalCompiler) produce the
> Lintian error "embedded-zlib", I cannot upload a new version of a package I
> maintain which overrides this error. (It's not allowed to override it at
> time)
You can override this. I do so for plt-scheme.
> So I started some research why this error is shown. FPC - generally - does
> not link any lib statically, so this ZLib error is bit strange.
> How does Lintian detect the embedded zlib in binaries?
From /usr/share/lintian/checks/binaries:
if ($info->field('source') ne 'zlib' and $info->field('source') ne 'klibc'
and $strings =~ /(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])/m) {
tag "embedded-zlib", $file;
}
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega
signature.asc
Description: Digital signature
Re: Binary package names for mozilla plugins
On Mon, Apr 26, 2010 at 3:54 PM, Hans-J. Ullrich wrote: >> Benjamin Drung writes: >> > Hm, browserplugin-* would be a new option. Then we would have >> > >> > 1. browser-plugin-* >> > 2. browserplugin-* >> > 3. *-browserplugin >> > 4. *-browser-plugin > > I think, 3 and 4 are the better choices than 1 or 2. IMO, the best choice > might be 4. Let me just explain why: > > If people are looikng for something, they first look, what application it is > in > for. Browser plugins might be available for iceweasel, konqueror, opera > whatever. So, the first choice is "iceweasel-", then what is it? This discussion is about packages which provide an NPAPI-compatible plugin. This means that the plugin works for any browser which supports the standard NPAPI plugin interface. Therefore, there is no reason to have a specific browser name in the package name and should instead use a common naming convention. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i2t14ccba101004261318r168411cfv45731a4ee5fac...@mail.gmail.com
Re: /usr/bin/mail policy
On Fri, May 7, 2010 at 12:17 PM, Florian Weimer wrote: > bts from devscripts invokes mail with an -a flag, which has different > meanings in bsd-mailx and heirloom-mailx (the latter being some > sort-of-default in squeeze installations, apparently). This has been brought up in #577564 as well. The subject is a little misleading since, at the time, I was under the impression mailx provided the functionality we needed while mail didn't. > I'm not sure which package is at fault here. Any suggestions? This is done to add extra headers to the mail being sent. The User-Agent header is always added and when --no-ack is specified the X-Debbugs-No-Ack header is also added. Since heirloom-mailx (and any mailx following the POSIX spec) doesn't have a way to specify extra headers, I've been considering changing this. X-Debbugs-No-Ack can be set as a pseudo-header and the User-Agent header was only added in response to #493884. While the User-Agent header is useful, I could see backing out this change so bts doesn't require the non-standard -a flag. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/o2r14ccba101005070944n110cd9a2w4c5ee6a1c6cd6...@mail.gmail.com
Re: /usr/bin/mail policy
On Fri, May 7, 2010 at 2:18 PM, Bernd Eckenfels wrote: > In article > you wrote: >> Since heirloom-mailx (and any mailx following the POSIX spec) doesn't >> have a way to specify extra headers > > What about using /usr/sbin/sendmail? Currently, our mail sending mechanisms fall into two categories: either $DEBEMAIL or $EMAIL is set or they aren't. For the former, one of mutt, sendmail, or a direct smtp connection is used to send the email. For the latter, we use mail to generate a From address for us and send the email. If people consider it acceptable to require $DEBEMAIL or $EMAIL to be set, then I have no problem removing our use of the mail command. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/g2u14ccba101005071234ub235a1bfv12cabf8144f80...@mail.gmail.com
Re: UPG and the default umask
On Wed, May 19, 2010 at 3:10 PM, Aaron Toponce wrote: > On 05/19/2010 01:00 PM, Philipp Kern wrote: >> When I do "newgrp " it's still UPG and the umask should still be >> 2, no? This check would change my umask. > > If the new default group is named something other than your username, > it's no longe UPG. UPG is only if the user name and group name match, > and the user is the only member of that group. > > So, to answer your question, if your username was "foo" and you belonged > to group "foo", of which you are the only member, then you do a "newgrp > bar" for foo, foo is no longer in a UPG situation, so his umask should > be 0022 at that point. Except /etc/profile won't be sourced again unless "newgrp - " is used, right? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimillfzkvbwdk2ruzmldg88pjmjtvhskvuyl...@mail.gmail.com
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 10:47:47PM +0200, Thomas Weber wrote: > How many packages are we talking about here? Is there a way to get the > number of packages that have the same version in Lenny and Squeeze? According to a quick query on UDD, there are 3169 source packages which have the same source version in Lenny and Squeeze. 746 when comparing Etch and Squeeze. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: Recent changes in dpkg
On Sat, May 29, 2010 at 02:17:27PM +0200, Thomas Weber wrote: > So, we are talking about 1000 packages which are up-to-date in > unstable currently. Bugs don't change that picture much. I consider this > manageable during a full cycle. > > And frankly, arguing back and forth about this is an exercise in > futility: > Is the new format worse than the old one? No. > Does it offer advantages over the old one? Yes, maybe not for all > packages, but for some. > So, let's make life easier for the dpkg developers and convert our > packages. There's no requirement to convert packages. All that's being requested is that the package be explicit about the source format. There's no reason to perform an upload *just* to make that change. There are currently 11.7k source packages which aren't explicitly declaring their source format. That's not going to change overnight and the Dpkg developers have already stated that the deprecation of an implied source format is a long term goal (likely Squeeze+2). -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 06, 2010 at 12:28:27PM +1000, Erik de Castro Lopo wrote: > Did anyone see this paper: > > A Look In the Mirror: Attacks on Package Managers > http://www.cs.arizona.edu/~jhh/papers/ccs08.pdf See the previous discussion that already happend on this list: http://lists.debian.org/487753dc.5020...@cox.net -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: vim transition to python 2.6
On Mon, Jun 14, 2010 at 01:18:39PM +0300, Oren Held wrote: > Currently vim packages (vim-nox, vim-gtk) on sid are still linked to > the old python2.5. > (Even though it seems possible to compile with python 2.6, according > to the debian-vim changelog changelog and bug #566842) > > Being linked with an old Python version, vim python plugins tend to > fail when they encounter new 2.6 syntax. > > Why is this transition delaying? Is there any task left which I can > help with? Vim will be built against Python 2.6 when Python 2.6 becomes the default Python version. If you want to help achieve that, take a look at the bug list for that transition: http://tinyurl.com/Py26Transition -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: How to warn about need to port changes to new configuration file?
On Fri, Jun 18, 2010 at 10:46 AM, Michael Biebl wrote: > On 18.06.2010 16:06, Thomas Hood wrote: >> It is planned that an upcoming version of resolvconf will add a new hook >> script for isc-dhcp-client which is identical to the existing one for >> dhcp3-client. An administrator who has made local changes to the latter >> hook script should probably make the same changes to the former. >> >> Is there a need to warn the administrator that he should (presumably) >> re-implement his changes in the new file? If so, what is the best way >> to warn him? Should debconf notes be used? > > I assume the file in question is a conffile. If you just want to move its > location, read the section "Moving a conffile" at > http://wiki.debian.org/DpkgConffileHandling dpkg-maintscript-helper was introduced in dpkg 1.15.7.2 to provide a standard implementation of actions like this. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikux_6xkwud9ppo8h-_w7zn_nxnypx63gqox...@mail.gmail.com
Re: xulrunner 1.9.2 into sid?
On Tue, Jun 29, 2010 at 3:50 PM, Michael Gilbert wrote: > On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote: >> Hi! >> >> Am 29.06.2010 17:24, schrieb Michael Gilbert: >> >> > No, my proposal is to move the package to a better home: backports. >> >> You don't know the current policies WRT packages in backports and about >> their reasoning, do you? > > I believe I do. Backports are for recompilations of unstable packages > for the stable releases. No, the backports service is for backporting packages from testing to the stable release. If a package (or the candidate version) does not exist in testing, then it is not a candidate for backports except under special circumstances. A package still has to go through some sanity checking (via the unstable -> testing transition) before being available for backporting since packages targeted for use with the stable release are supposed to be exactly that -- stable. This means stable both in the sense of working properly as well as not being a moving target because of behavior changes introduced in newer versions. The proposal to maintain the packages entirely in backports is not congruent with this. It sounds closer to the intent of volatile, although I don't think that's a proper place for the packages being discussed either since volatile is for packages which, more by necessity, need to have multiple updates during the span of a stable release. This is not the case with the Mozilla-related packages, as new version updates (other than the security fixes already being handled) are a nicety, not a requirement. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiluxaygkyf0rln3hpivq13ax6m3n2qsmqaw2...@mail.gmail.com
vim-tiny in base (was Re: Priority dependence)
On Mon, Jul 19, 2010 at 04:45:56PM -0700, Russ Allbery wrote: > "brian m. carlson" writes: > > > The vi and nano debate was had a long time ago. So was the nvi versus > > vim-tiny. It was decided that first-time users were not going to be > > able to navigate vi, but experienced users would expect it. I don't > > know why people argued for vim-tiny over nvi; for a really rudimentary > > base system, I think smaller is better. > > There was a long argument at the time which mostly amounted to, if I > remember correctly, vim having a more active upstream. FWIW, if I knew then all the issues that I've had to deal with from that change (primarily very confused users, but also hassling with diversions under a versioned directory and having to carry a non-upstreamable patch), I probably would've argued against the change among my fellow Vim maintainers. I think the vim-tiny package has ended up being more work than it's worth. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: dkms needs a pre-depends entry (Policy 3.5)
On Tue, Jul 20, 2010 at 4:01 PM, Bernd Zeimetz wrote: > On 07/20/2010 09:50 PM, Julien Cristau wrote: >> On Tue, Jul 20, 2010 at 21:44:21 +0200, Bernd Zeimetz wrote: >> >>> On 07/20/2010 09:08 PM, Philipp Kern wrote: >>>> Well, that lsb_release is written in Python is just an implementation >>>> detail, no? So it just should not be the responsibility of the caller. >>> >>> It should as you can't assume that your dependencies are configured when >>> your >>> own package is being configured (Debian Policy 3.5). >> >> Where in 3.5 do you read that? > > Sometimes, a package requires another package to be installed and configured > before it can be installed. In this case, you must specify a Pre-Depends entry > for the package. > > We have exactly this case here. lsb_release needs to be configured first. 3.5 is an overview. 7.2 has the details: Depends This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilfd44s7gbgrlpgxyrogqv5ixstsfzzwfurn...@mail.gmail.com
Re: question: startscripts
On Wed, Jul 21, 2010 at 4:12 PM, Hans-J. Ullrich wrote: > Am Mittwoch, 21. Juli 2010 schrieb Yaroslav Halchenko: >> I am sorry, probably I am missing the point but isn't it RTFM issue in how >> to use sysv-rc to be able to revert back easily... e.g.: >> > Hi Yaroslaw, > > sorry, I described it not quite clear. It is not the problem of sysv-rc, as > after the change to sysv-rc everything worked well for months. > > But after an update some time ago, I got some problems with some starting > timings. To specify: kdm/gdm/xdm is not staring at boot (and only at boot). > When the computer is started, the command "/etc/init.d/kdm restart" let kdm > startr like a charm. If you have an nVidia card, it may be that KDM is not waiting long enough for the video card to be initialized[0][1]. [0]: http://bugs.debian.org/583312 [1]: http://bugs.debian.org/583336 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilzor8zd1o9z0skwucltbcsctfyxxlxyt6i4...@mail.gmail.com
Re: Notes from the DebConf Source Format BoF
On Wed, Aug 11, 2010 at 10:31 AM, Wouter Verhelst wrote: > On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote: >> source.debian.org is working on importing source packages into a Git >> repository and storing the history as one revision per new source package >> upload. > > That gives a 404. source.debian.net doesn't, but gives you a page with > as full contents the eight characters 'hallo...' According to <http://wiki.debian.org/source.debian.org> it's still in the idea/planning phase. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikqdey_dzg=lcog-68jnwgpazqzs6cdrba8q...@mail.gmail.com
