Re: Proposal: SystemD.pushers/forcers be physically beaten as revenge.
On Tue, Feb 11, 2014 at 02:46:13PM -0500, Maas Verri wrote: > The people, such as Adrian, who are pushing systemd as the one > and only init system for debian should be physically harmed. You are way out of line. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- 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/20140211201106.gc3...@kukkavihko.kaijanaho.fi
Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package
On Mon, May 13, 2013 at 02:52:17PM +0200, Alberto Garcia wrote: > Also, is there any relation between this and the old 'debmake' package > or they just happen to have the same name? My first thought upon seeing this ITP was, whyever for would anyone want to resurrect debmake. Please choose another name. -- Antti-Juhani Kaijanaho -- 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/20130514074357.ga10...@teralehti.kaijanaho.fi
Re: Automatically satisfying Build-Depends from local control file
On Thu, Apr 18, 2013 at 07:21:32PM -0700, Nikolaus Rath wrote: > No, it's not quite as bad. The following works as well: > > dpkg --force-depends -i build-deps.deb && apt-get -f install Why force-depends? Why not dpkg --unpack? -- AJK -- 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/20130419084359.ga5...@teralehti.kaijanaho.fi
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
On Thu, Aug 16, 2012 at 05:41:08PM +0200, Alexander Wirt wrote: > What let you think this? Carelessness in investigating (looked at http://packages.qa.debian.org/libp/libpam-ssh.html, noticed that the last news entry was removal from testing and did not read closely enough to notice the unstable removal notice below it - in retrospect, I should have expected such a pattern, as removals from testing are often preceded by removals from unstable). Sorry for the noise. (I do not need a personal CC, by the way. I am subscribed.) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- 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/20120816155600.ge2...@kukkavihko.kaijanaho.fi
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
On Thu, Aug 16, 2012 at 05:39:50PM +0200, Jerome BENOIT wrote: > According to its PTS ( http://packages.qa.debian.org/libp/libpam-ssh.html ): > [2011-12-03] libpam-ssh REMOVED from testing (Britney) > [2011-12-02] Removed 1.92-14 from unstable (Alexander Reichle-Schmehl) > > So I guess it must be considered as removed. Yes, you are right. Sorry for my careless reading of that page. In any case, no ambiguity, it seems. I don't think a package's presence in stable or oldstable alone is a problem. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- 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/20120816154232.gd2...@kukkavihko.kaijanaho.fi
Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys
On Thu, Aug 16, 2012 at 04:14:07PM +0200, Jerome BENOIT wrote: > The situation is ambiguous as I posted before in the > debian-devel@lists.debian.org list: > the package is not orphaned, was removed but it is still present. There is no ambiguity. The package is present in unstable and thus is not "removed" in the sense that word is commonly used without qualifiers. (The proper way to describe what happened to the package is "removed from testing" - a release engineering action that doesn't imply any change in a package's maintainership.) > There is a void here, and it is why I asked on the list: it was suggested to > make an ITP since it was removed. An ITP is inappropriate so long as the package is present in unstable or experimental. > It appears that the Maintainer has retired from Debian. In that case, the package likely is available for salvaging (that is, for taking over maintainership without going throug a period of formal ITA or O period). -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- 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/20120816153138.gb2...@kukkavihko.kaijanaho.fi
Re: Re: Re: [CTTE #614907] Resolution of node/nodejs conflict
On Mon, Jul 23, 2012 at 09:08:25AM +0100, Lars Wirzenius wrote: > Yes, conflicts certainly are inevitable. When they escalate to the second > highest decision-making body in the project, which makes a decision, > that is clearly important enough that it warrants an announcement to > the entire membership of the Debian project. I agree. > an analogy with the legal system may make things clearer: the press does not > announce every decision made by every judge in a court of law, but it does do > so for every decision made by the supreme court, whether the case as such is > of general interest or not. I doubt that's true, though (unless one includes specialized press such as SCOTUSblog in the US). In any case, the analogy is faulty: it's not like the Supreme Court buys advertisements (or compels publication of stories about its decisions) - it just puts the decisions out there where journalists can see them and allows them to pick and choose stories that would interest their readers. The main reason I think the TC should continue posting their decisions to d-d-a is that their decisions are exceptions to the usual Debian decisionmaking. Each one of them should evoke a sense of shock - why didn't the usual processes work in this case?[*] - and they cannot do that if they are not widely published. A policy of posting all such decisions to d-d-a also gives the developers a sense of how frequent such exceptional cases are and serves as a crude measure of project health. Even a conspicuous absence of such postings would be significant, as it's a bit like a body temperature: too hot is a sign of illness, but too cold also signifies that something's not right (usually the thermometer has broken down). There's also the aspect of oversight by the developers by way of general resolution, but I think that is a minor issue. If the TC makes such a bad decision that it warrants reversal by GR, the developers who were party to the dispute are quite able to make the case known even if the TC's decisions weren't widely known in general. (As a matter of personal policy, I would vote to affirm the TC's judgment even if I disagreed with it, unless it's grossly irregular or grossly broken.) [*] In the past, when I wasn't lurking on the -ctte mailing list, each decision I became aware was indeed a shock to me, and I went to the archives to see what had happened. Now I watch the horrors live :-) > the total volume of supreme court decisions is quite low. Not quite. Although the US Supreme Court issues less than a hundred merits decisions a year, they make a lot more summary decisions (mainly denial of certiorari - they exercise their discretion not to hear a case) each year, most of which even the courtwatcher press does not note. The numbers are similar, I believe, for the Finnish Supreme Court. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: scim and assorted packages
On Wed, Jun 27, 2012 at 07:30:11PM +0200, Toni Mueller wrote: > today I received an email from the FTP masters that a pacakge that is > highly relevant to me, has been pulled from Debian. Why not name the package in question? It does not appear to be scim, which is what you wrote in your subject line. Looking at the removal log, I see scim-tables was removed today. I assume you are referring to it. > how I can stay at the front of this. The package was orphaned in February and removal was requested in May[1]. Thus there was plenty of time to "stay at the front of this" if you had wished to. I'm pretty sure the PTS[2] shows such actions prominently, and it's a good idea to visit the PTS page of any package you really care about every once in a while. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659309 [2] http://packages.qa.debian.org/s/scim-tables.html I believe it's possible to reintroduce the package if there's a willing and able maintainer, but it'd need to go through NEW again -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ -- 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/20120627175338.ga5...@kukkaseppele.kaijanaho.fi
Re: duplicates in the archive
Svante Signell kirjoitti: >On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote: >> Which wm does that? I know it isn't gnome-shell at least, as I've >been >> using it quite successfully without nm installed. > >Have you tried to use evolution without NM? Evolution is not, so far as I know, a window manager. And no, I have never used it, with or without NM. -- 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/8953d159-a56b-4756-8b12-383af507e...@email.android.com
Re: duplicates in the archive
Adam Borowski kirjoitti: >Sure, let's start removals with ones that hard-depend on things a >window >manager shouldn't touch, like network-manager. Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. (I hope this message looks okay - I'm sending from an unfamiliar MUA.) -- Antti-Juhani -- 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/1eb44713-6893-4e9d-9cb5-9fd07e0c5...@email.android.com
Re: Lintian warning: hardening-no-fortify-functions & version numbering
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote:
> repository but not still in a numbered version, so, I tried to use the
> latest known version and add a ~TIMESTAMPgit... to the minor version
> number, but debuild warns me about the version 0.1.0~2012..git-1 is
> less than 0.1.0.
Use A~B only if this version should come before A - that is, for example, if
you expect the next upstream release to be A. In your case, use A+B so the
version comes after A in version order.
> The latest thing is that I have seen several packages with ~TIMESTAMP
> (screen, by example): they add a alpha-numeric string after the "git"
> word... what does it mean?
It's the beginning of the hash git uses to uniquely identify the version.
You can see the full hash in, for example, git log, at the beginning of each
patch:
commit 2ff04fd5a95f36497bc8e8c6e44d70c474384ec2
Author: Antti-Juhani Kaijanaho
Date: Mon Jun 18 23:26:59 2012 +0300
Add install-sh
Signed-off-by: Antti-Juhani Kaijanaho
In this case, the hash is the long string after the word "commit"
on the first line, and I would use for example 2ff04 in the version number if I
packaged this version as a git snapshot.
> Where can I found some information about
> packaging directly from VCS?
git-buildpackage has excellent docs. You don't have to use the tools but they
help.
--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
signature.asc
Description: Digital signature
Re: Relation between Suggests and Enhances
On Tue, Aug 18, 2009 at 09:13:42PM +0200, Andreas Tille wrote: > What exactly means "similar". Assume package foo enhances package bar. > Does this mean that in turn package bar should Suggest package foo or > is this conclusion not really valid? As I understand it, "A enhances B" has (more or less) the same effect as "B suggests A". Thus, the reverse Suggests relation would be redundant. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: I hereby resign as secretary
On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote: > I am hereby resigning as secretary, effective immediately. Thank you for all the good work you've done in that position over the years. > As to the people who emailed me that they are putting together a > petition for the DAM to have me removed from the project, I hear you > too. I am going to spend the next few days evaluating how important the > project is to me, and whether I should save you the bother or an > expulsion process. I would just like to go on record that if Manoj is expelled from the project due to the recent events, then I will resign. Fortunately, it seems that it won't be necessary. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: First call for votes for the Lenny release GR
On Mon, Dec 15, 2008 at 01:59:27PM +0200, Kalle Kivimaa wrote: > Antti-Juhani Kaijanaho writes: > > Doesn't it occur to you that there might be a reason why the Secretary > > cannot > > be removed by GR or by the Leader's whim? > > Actually, the Secretary *can* be removed by a GR. The GR must of > course amend the Constitution at the same time to allow this, so it > needs to be done with a 3:1 majority. Point :) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
On Mon, Dec 15, 2008 at 12:59:01PM +0100, Adeodato Simó wrote: > What does §4.1.7 mean, then? Can't it be read to mean that the DPL may > appoint a new Secretary not at end of term, if there's disagreement > between them? I read it as a reference to the second paragraph of Section 7.2. Notice the difference to point 1 in the same section - the Developers by way of GR aren't explicitly authorized to recall the Secretary, like they are for the DPL. But your interpretation is certainly possible. Of course, that just means it's up to the Secretary to rule which (if either) is correct :) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: First call for votes for the Lenny release GR
On Mon, Dec 15, 2008 at 09:50:29AM +0100, Pierre Habouzit wrote: > Is there someone on the plane here to do what's needed with the > secretary? If the DPL isn't willing to take any action here (and I'm > really annoyed that despite repeated questions about it he never showed > up in the discussion[0]), I believe I'm willing to start a GR (*SIGH*) > about it[1]. The only constitutional way to get rid of the Secretary without his consent is for the DPL to fail to reappoint him, which would automatically mean (since I'm assuming that the Secretary does not go willingly) that a replacement Secretary is selected by the Developers by way of General Resolution. I'm not sure when the current term of the Secretary expires, but I'd guess it'd be some time after the next DPL election. > going on. Right now we see blatant power abuse, with the DPL being > completely OK with it. Sooo nice. We don't, in fact, see blatant power abuse. > [1] I know that the constitution doesn't state that we can rescind our > Secretary through a GR, but I would be _really_ surprised that if > such a GR passes, the Secretary wouldn't resign. Doesn't it occur to you that there might be a reason why the Secretary cannot be removed by GR or by the Leader's whim? Given that, I would be most disappointed if (a) the Secretary would consent to running an unconstitutional GR vote and (b) be weak enough to submit to pressure to resign because of his actions (assuming he himself believes he's acted within his powers). Similarly, I am somewhat alarmed that some people consider it legitimate to pressure the Secretary to resign, or to consider extra-Constitutional means of removing him from office. The correct way to deal with this is to wait until the current bundle of votes is over, and then propose Constitutional amendments that create mechanisms for Secretarial oversight that you'd consider appropriate. (I personally have a proposal cooking. As you have no doubt noticed, I have strongly supported the current Secretary, and I continue to have faith in him - but the current furor has exposed certain Constitutional flaws I would like to have corrected. The time for fixing them is not now, however.) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: First call for votes for the Lenny release GR
On Sun, Dec 14, 2008 at 12:03:17PM +0100, Pierre Habouzit wrote: > Unless I'm mistaken this shouldn't be [3:1] as it's specifically allowed > by the § about delegates in the constitution. "Delegates shall take > decision they see fit". What should be [3:1] is to dis-empower them from > having such rights. You are mistaken :) Your quote comes from Section 8.3 "Procedure". Its meaning is that the constitution specifically does not require the delegates to follow a particular procedure to reach their decisions. It does not talk about what authority the delegates have (that is discussed in Section 8.1 "Powers"). -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Info on Planet Debian
On Tue, Nov 25, 2008 at 03:33:59PM +0100, David Paleino wrote: > just out of curiosity: is there a procedure to follow to be added to Planet > Debian's feeds? Does one get automatically added when she becomes DD? Are only > DD "allowed" to post on Planet? See http://wiki.debian.org/PlanetDebian -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: For those who don't learn to choose sane subjects (Was: For those who care ...)
On Mon, Nov 24, 2008 at 08:04:38AM +0100, Mike Hommey wrote [edited by AJK]: > Do you know where I could find [the music-related thing that shall not be > named] ? Groan :) -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SmellyWerewolf.com perfume & make-up discount
On Sun, Nov 23, 2008 at 05:32:12PM +, Steve Kemp wrote: > On Sun Nov 23, 2008 at 17:59:13 +0100, Josselin Mouette wrote: > > > - Send your private Debian GPG Key to [EMAIL PROTECTED] Include > >the brand of your perfume and the color of the make-up. > > I find it disappointing to see this posted, and in bad taste. I found it generally hilarious and a well-made point, though I agree the presentation could have been in better taste. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Bug#448284: RFH: dctrl-tools -- Command-line tools to process Debian package information
Package: wnpp Severity: normal I request assistance with maintaining the dctrl-tools package. There are several tasks that could use more manpower (in no particular order): 1. Writing test cases One could mine the BTS for past bug reports and create regression tests for them. One could use standard black-box and white-box testing techniques to generate general tests. 2. Writing documentation The whole suite of tools could use a unified tutorial manual on how to best use it. The current documentation is reference material in the man pages. 3. Internationalise the man pages Use po4a? 3. Swatting the BTS wishlist entries I've kept the BTS clean of actual bugs pretty well, but there are a number of wishlist reports still outstanding. 4. Take over maintaining the debian/ directory If you commit to maintaining it (and I trust your judgment), you'll get last say in that part of the package (including deciding what helper to use). 4. Whatever you wish :) Discuss on the dctrl-tools-devel mailing list first though. Eventually I'd like to pass the package on to competent successors, but I have too much emotional attachment to the package to do that without a transitional period where I still retain a veto on what goes in the package. I also have some ideas for future tools that I'd like to be able to concentrate on, and having co-maintainers might allow that. The package is now under Git in collab-maint. See http://git.debian.org/?p=collab-maint/dctrl-tools.git;a=blob_plain;f=debian/README;hb=HEAD for information and a push-access code of conduct. The package description is: Debian package information is generally stored in files having a special file format, dubbed the Debian control file format (the dctrl format), a special case of the record jar file format. These tools operate on any files conforming in a general sense to that format and are therefore widely applicable whenever those formats are in play. . Included are: . grep-dctrl - Grep dctrl-format files grep-available - Grep the DPKG available database grep-status- Grep the DPKG status database grep-aptavail - Grep the APT available database . sort-dctrl - Sort dctrl-format files . tbl-dctrl - Tabulate dctrl-format files . sync-available - Sync the dpkg available database with the apt database -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23.1-ibid (SMP w/2 CPU cores; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 manual pages
On Thu, Oct 11, 2007 at 12:42:49PM -0400, Joey Hess wrote: > The manpage:encoding idea could work, but might have ambiguity issues > with man pages with colons in their name I think that's solvable by taking the last colon. I don't think encodings have colons in them. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 09:48:07AM -0500, John Goerzen wrote: > I don't know about that. Hasn't it been a long-standing policy that bugs > that get no response from the submitter to questions can be closed? I know of no such policy. However, it has been common practice to do that for bugs that the maintainer cannot reproduce based on the information at hand. This is not the case being discussed. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
On Tue, Oct 02, 2007 at 08:02:25AM +1000, Ben Finney wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 01, 2007 at 08:57:07PM +, Pierre Habouzit wrote: > > > Asking *kindly* some help from the submiter, once or twice a > > > [year], is not an insult. > > The insult isn't the request for help. The insult is the implication > that if there's no response, the bug will be summarily closed with no > attempt made to see if the problem reported is fixed. This is true. However, I find more insulting the kind of mails where it is obvious that the sender has not tried the reproduction instructions given in the bug logs. I tend to answer such mails in a very irate manner (but I do answer them, and I do also do what the sender should have done - that is, try the reproduction instructions). The insult is that the sender clearly has not even read the bug logs. The situation is of course different when the sender honestly *cannot* reproduce the bug (for example, because the instructions are confusing, or the sender does not have access to the hardware required). The bug report from which this thread started is similar (but not identical). The sender should have noticed that it was a wontfix bug (this doesn't even take reading the bug log!) and not sent any mails to it as the proposed cleanup procedure is clearly not applicable to wontfix stuff (either the bug should be closed immediately or it should not be closed even with no activity, depending on the maintainer's preference). I'm grateful that people volunteer to triage bugs, but volunteering is no defense for making mistakes. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: pbuilder and configure
On Wed, Sep 19, 2007 at 06:00:06PM +0900, Atsuhito Kohda wrote: > It's lynx-cur and it has an ability to mail so it is > necessary to know what MTA is available, I guess. Is it not possible to tell it? Something like --with-sendmail=/usr/sbin/sendmail -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder and configure
On Wed, Sep 19, 2007 at 04:57:36PM +0900, Atsuhito Kohda wrote: > One additional question. In case MTA, for example, there are > many candidates including virtual package for Build-Depends. > > I guess "exim4-daemon-light | mail-transport-agent" > will be acceptable. Is this okay? Why would you need a MTA to build a package? -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder and configure
On Tue, Sep 18, 2007 at 11:03:15PM -0700, Russ Allbery wrote: > The solution is indeed to have a proper Build-Depends. Also, it is a good idea to disable feature autodetection and enable wanted compile-time features explicitly, like this: ./configure --enable-packager-mode --enable-foo --enable-bar \ --prefix= ... Of course, not all packages support packager mode, but some do. Even if it is not supported, it is a good idea to --enable and --disable stuff explicitly. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: changes to default password strength checks in pam_unix
On Mon, Sep 03, 2007 at 11:40:07PM -0400, John Kelly wrote: > I stop brute force attacks by sending auth log messages to a FIFO which I > read with a perl script. After 10 login failures, your IP is firewalled for > 24 hours. I have a rate-limiting iptables ruleset for SSH (and HTTP). In my experience, brute force attackers give up after the rate-limiter starts tarpitting them. See http://antti-juhani.kaijanaho.fi/stuff/ratelimit.txt - Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Bug#439940: ITP: darcs-monitor -- Darcs add-on that sends mail about newly pushed changes
Package: wnpp Severity: wishlist Owner: "Antti-Juhani Kaijanaho" <[EMAIL PROTECTED]> * Package name: darcs-monitor Version : 0.3.1 Upstream Author : Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> * URL : http://wiki.darcs.net/DarcsWiki/DarcsMonitor * License : GPL2+ Programming Lang: Haskell Description : Darcs add-on that sends mail about newly pushed changes It is often desirable to send mail about new changes to software to a mailing list as soon as they are committed to a version control repository. Darcs-monitor adds this functionality to Darcs, an advanced revision control system. . Darcs-monitor is most commonly used as a Darcs apply post-hook, so that email is sent as soon as changes are pushed to the repository under monitoring. . Mails sent by darcs-monitor are configurable, and they can contain the diff of the changes, as well as change metadata. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating NEWS.Debian
Please don't CC me, as I read the list. On Thu, Aug 09, 2007 at 10:49:33AM -0300, Henrique de Moraes Holschuh wrote: > On Thu, 09 Aug 2007, Antti-Juhani Kaijanaho wrote: > > The reason? It's counterproductive and silly, when upgrading from > > oldstable to stable, to get lots of news that was ever relevant only for > > sid-to-sid upgrades. > > Better to do that cleanup near the freeze, if at all. Otherwise, once could > easily be causing trouble for the people following unstable and testing. As long as you actually do that cleanup before the freeze, that's OK :) But if there's a chance you won't have the opportunity, do it now. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Updating NEWS.Debian
On Thu, Aug 09, 2007 at 11:08:46AM +0200, Peter Eisentraut wrote: > I have seen some packages lately, most prominently apache2, that replace the > entire NEWS.Debian file when they have some news to report. That way, older > news are lost, and users who don't upgrade to every intermediate version > (say, those who upgrade only between stable releases) are left in the dark. > So if you have been doing that, please don't, and put the old news entries > back at the bottom of the file. Bugs should probably be submitted about that > kind of misuse. I believe it is entirely appropriate to delete versions that never made it to a stable release, having the NEWS.Debian file contain an entry for each stable release and for the current release candidate version (generally, the current version in unstable); obviously, any of these may be missing if there is no news to report. The current version should contain all news that affect upgrades from the latest stable release to the current version. The reason? It's counterproductive and silly, when upgrading from oldstable to stable, to get lots of news that was ever relevant only for sid-to-sid upgrades. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: [CMake] Producing deb package with 'ar'
Please don't CC me, I read the list. On Mon, Aug 06, 2007 at 01:38:33PM +0200, Mathieu Malaterre wrote: > thanks for the link. So according to this page I might even be able to > generate a single tarball: You do need the .dsc too :) -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [CMake] Producing deb package with 'ar'
On Mon, Aug 06, 2007 at 12:34:40PM +0200, Mathieu Malaterre wrote: > I am currently working on integrating debian packaging system in > cpack (part of CMake, see cmake.org). Basically cpack used to have a > simple tarball system for creating package on *NIX. I simply had to > encapsulate this tarball within an 'ar'ball, with a control and a > md5sums file (*) I recommend reading the deb(5) man page; there may be surprises. > I am now wondering if I should also create some sort of debian > 'source' package. As far as I understand there is no such thing, but > instead your are distributing a copy of the original tarball of the > package and a diff file. Is this correct ? It's not. A Debian source package consists of two to three files. The main file has the suffix .dsc; it specifies source package metadata and what other files are needed. The other files are a tarball and an optional diff. See http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-sourcearchives . Also note that packages intended for installation in a Debian system should follow Debian policy. This may be nontrivial to achieve using an automated system like (I assume) cmake. See http://www.debian.org/doc/debian-policy/ -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Can we require build-arch/indep targets for lenny?
On Mon, Jun 18, 2007 at 04:40:26PM +0200, Thomas Viehmann wrote: > Wouldn't looking for the output > make: *** No rule to make target `build-arch'. Stop. > and then defaulting to make build be an option? This was discussed and rejected back when the build-* targets were proposed. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ signature.asc Description: Digital signature
Re: Pushing multi-arch media (Re: blockers for 64-bit adoption)
On Mon, Apr 09, 2007 at 03:51:54PM +0200, Alexander Schmehl wrote: > The multiarch media still has a small problem: for i386/amd64 they are > no "fire and forget" thing; you still need to find out if you have an > amd64 compatible system and start the amd64 boot process by hand. > > It would be really cool, if that could be autodetected... but I don't > know how that could be done. Check if the processor has support for long mode? AIUI it only takes a bit of assembler to do it (on a Linux system you can look for "lm" in /proc/cpuinfo, but I suspect this has to be done before Linux is booted). signature.asc Description: Digital signature
Re: Real Life hits: need to give up packages for adoption
Christoph Haas wrote: Darcs looks like a nice competitor but has some issues regarding checking in changes automatically (might as well be my ignorance but it sounds like I need weird scripts and a .procmailrc to merge changes automatically). You don't *need* them; you can choose to do that, but you can also choose otherwise. There are two ways to give contributors "commit access" in darcs. (I'm using quotes because in Darcs, "commit" is an ambiguous term and is usually avoided; I'm using it here to mean incorporating a change in a special project-wide shared repository.) *** Way One --- Set up an email address which feeds messages to darcs. Darcs is capable of checking GnuPG signatures in these mails and only allowing known keys to "commit". The contributor "commits" by using the "darcs send" command. The upside is that the contributors do not need shell access to the server. The downside is that setting this up is not very easy. Way Two --- Give contributors shell access to the server; make the shared repository writable by all these accounts. The contributor "commits" by using the "darcs push" command. The upside is that this is very easy to set up. The downside is that you need to give contributors shell access. (I suppose a restricted shell is possible. I haven't investigated this.) *** I personally prefer Way Two. I have tried Way One, but it isn't worth the trouble most of the time. What makes darcs special in my opinion is its support for second-class contributors: anybody can "darcs send" stuff to the project mailing list (if you've set stuff up for this; it's not very hard), the email is both human- and computer-readable: it can be eyeballed and it can be fed directly to darcs to incorporate the change to the local repository (from which it can be "committed" to the shared repository, if this is desired and one has the necessary "commit" privs). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When to drop/split/summ changelog files
Nico Golde wrote: I thought about changelogs like: 2001-04-06 mitch 20:18:29Michael Natterer <[EMAIL PROTECTED]> This is not a Debian changelog, and your original question talked about those. Many upstreams split their own changelogs occasionally. If you like, suggest to yours that they do this; don't do it on your own. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mass bug filing on packages that are blocking use of cdebconf
Joey Hess wrote: > [EMAIL PROTECTED]:~>apt-cache dumpavail | grep-dctrl -FDepends debconf \ > |grep-dctrl -FDepends -v '| debconf-2.0' | grep ^Package: \ > | cut -d : -f 2 | dd-list --stdin Assuming a sid grep-dctrl, grep-aptavail -FDepends debconf -a -! -FDepends '| debconf-2.0' \ -sPackage -n | dd-list --stdin :) (Sarge's grep-dctrl would need the apt-cache dumpavail | grep-dctrl start.) (Could be much faster if dd-list accepted input in the format output by -sPackage,Maintainer.) -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: Bug#325371: ITP: binfmtc -- a binfmt_misc hook for running C programs as scripts
Wouter van Heyst wrote: > Are you sure? http://fabrice.bellard.free.fr/tcc/ claims it produces > optimized x86 code, which could be a problem on other archs. TCC does some simple local optimizations (AIUI, some peephole optimization, and simple intra-statement linear register allocation), but calling it an "optimizing" compiler in the GCC sense would be too much. The TCC architecture would require significant changes if one wanted to make it a true optimizing compiler. However, TCC-compiled code is likely much faster than anything that the interpreters (Python, Perl) produce from equivalent code. -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: making developer location from ldap public?
Jesus Climent wrote: > At least in Spain and Finland, publishing such information without the consent > of the person would be against the law. True. In fact, our db.d.o database would, as it currently stands, be illegal in Finland, if it were located in Finland. (It'd be fairly easy to fix, actually. The main thing that is missing is formal documentation of the database as required by the law.) signature.asc Description: OpenPGP digital signature
Re: Bug#323227: new list: debian-planet to distribute planet.debian.org postings; archive to enable searching
Christoph Berg wrote: > I'd like to have a debian-planet list that would receive blog postings > from planet.debian.org While I agree that an archive of Planet Debian is desirable, I'm not sure this is the way to go. It seems to me that an archival feature to PlanetPlanet would be more worthwhile - that would preserve the Planet look and all the images that a typical RSS to email script doesn't. Besides, this list is badly named. Debian Planet and Planet Debian are two entirely different things. -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: Dogme05: Team Maintenance
W. Borgert wrote: > VIII. Packages not maintained by teams are not to go into > unstable/testing/stable. Does this mean you are volunteering as a team member for all packages that currently have only one maintainer? -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: Packaging a PostScript resource
Terry Burton wrote: > PostScript is an interpretted language, so I fail to understand what you > mean by source packages in this context. That word is part of the Debian jargon. You need to learn the essentials of that jargon before you can effectively package anything for Debian. The main source for this is the Debian Policy manual, which you should read in its entirety (not skipping things that on the surface look irrelevant). http://www.debian.org/doc/debian-policy/ > Copyright is included in the resource file. If this need to come out > into a COPYRIGHT file I can certainly do this. More of the same. > There are a number of high-level APIs for this code that are currently > in production including Java, Perl and Ruby. Also the resource is used > by the pst-barcode LaTeX package that is part of PSTricks and the > web-based demo at http://www.raise-the-bar.co.uk/demo. Your package should refer to those, then. -- Antti-Juhani signature.asc Description: OpenPGP digital signature
Re: controlling spam via mail interface?
On 20050804T200629+0200, Javier Fernández-Sanguino Peña wrote: > On Thu, Aug 04, 2005 at 07:47:18PM +0200, Frans Pop wrote: > > > > And yes, I expect that all messages reported will need to be manually > > reviewed to avoid deleting good mails from the archive. > > It would be cool if we could create a spam-reporting alias I seem to remember that we have (had?) one, back in the days when spam was counted in single digits per day. I have no idea if it still exists, or what it was called. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: fresh blood gets congested: long way to become DD
On 20050801T135912-0400, Roberto C. Sanchez wrote: > Maybe Laszlo wants to know which would be the proper pronoun reference. "Ey" is good for everybody, even the genderqueer. :) (Tip: ey talks to em about eir stuff) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: fresh blood gets congested: long way to become DD
On 20050801T153347-0400, Yaroslav Halchenko wrote: > So there are 12 AMs which are listed and which do not carry any load, > although the load is there and knocking the door :-) I don't know how many of those are in my position: I am practically a newbie as an AM and as such I will carry little weight until I have the procedure down for myself, which takes full processing of one candidate. After that, I will assess my limit as to how much load I can carry, and I will then start taking on more candidates. I would be surprised if I was the only new AM after the NM talk in Debconf :) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: RFC, problem with g++4
On 20050729T17+0200, Florian Weimer wrote: > > The problem is, your trick doesn't work outside templates, > > Huh? [After testing it:] I'll be damned. I was sure I was right :) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: RFC, problem with g++4
On 20050729T151821+0200, Florian Weimer wrote:
> Today,
>
> template
> struct Foo
> {
> static const unsigned N = T::N;
> char bar[N];
> };
>
> works and the enum trick lost its importance.
That is not a new trick, I'm fairly sure that was legal when I first
learned of the enum idiom. The problem is, your trick doesn't work
outside templates,
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
signature.asc
Description: Digital signature
Re: RFC, problem with g++4
On 20050729T16+0200, Olaf van der Spek wrote: > On 7/29/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > Florian Weimer <[EMAIL PROTECTED]> writes: > > Doesn't that still make N a real variable in memory and does not get > > optimized away like enums? > > I think it's (only) required to have an address. > I don't see why the compiler can't optimize it away (if it's const). Only if the compiler knows all uses of that constant. With dynamic linking, you can't know that very easily. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: RFC, problem with g++4
On 20050729T083332+, Brian M. Carlson wrote: > Of course, I could be persuaded that the enumeration is a good idea, but > I don't see what problem it solves, and it only seems to cause them. The anon enumeration trick has been an established C++ idom for years (ISTR, but cannot check now, even Stroustrup himself advocating it). It's a shame if it now suddenly stopped working and is somehow against the standard, even. The problem with #defines is that they're outside the language proper and, for example, pay no attention to namespaces. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On 20050717T213903-0700, Thomas Bushnell BSG wrote: > Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes: > > > On 20050716T195244-0700, Thomas Bushnell BSG wrote: > >> That's a far cry different from someone wanting to enforce a > >> requirement. > > > > Who, in this thread, is this hypothetical someone? > > Right. Manoj asked: why should we have a requirement? Someone said > "here's why!" and I am simply pointing out that you can get what he > wanted without a requirement. My mistake then. My other comments, not directed at you, still apply, though. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On 20050717T025707-0500, Manoj Srivastava wrote: > A little reading comprehension on your part would help a bit > here. Hint: dict policy would help. > > The discussion started wuth a wuestion of _policy_. Once you > comprehend what that word means, you'll see what Thomas meant. I distinctly remember you arguing that Policy is not a stick to beat people with. How then, in your opinion, could the mere mention of the word "policy" imply wanting to enforce anything? Assume the best possible motivations, please. In this case, it could go a long way if people would read "policy" as "the DDR" when such a reading makes a question make perfect sense (and, if they must, politely correct the error). Some people actually did that. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On 20050716T195244-0700, Thomas Bushnell BSG wrote: > That's a far cry different from someone wanting to enforce a > requirement. Who, in this thread, is this hypothetical someone? As far as I can tell, this thread started with a simple question: is there a policy for a certain thing? There were a couple of honest responses, Then we have a lot of whining about how the younglings cannot think for themselves from people who should know better, and a mini-flamewar based on those thoughts, but I haven't seen anyone talking about enforcing anything, until now. Where did the old-fashioned practice of reading comprehension and assuming good intentions (instead of stupidity or malice) go [1]? (No, this isn't directed solely, or even mainly, at you:) [1] Yes, there are situations where you should assume malice, but debian-devel discussions aren't one of them - and there is no situation where assuming stupidity is better than assuming good intentions. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: should etch be Debian 4.0 ?
On 20050708T181259-0400, Johan Kullstam wrote: > I've never understood the .X distinction anyway. > > What signal is meant by 3.1 versus 4.0? Does your intended audience > have any concept of the distinction? The usual distinction, when it is made, is that bumping the major number indicates a disruptive upgrade (changing how things work, not just adding new things). I suppose I should advertise my version number rant here: http://antti-juhani.kaijanaho.info/blog/en/programming/version-numbering.html -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Why apt-get is not a proper software search engine
On 20050612T203113-0700, Russ Allbery wrote: > (For that matter, the dpkg delay on "Reading database" is kind of annoying > too. Hm. Good project for someone.) I've noticed that dpkg --clear-avail && dpkg --forget-old-unavail speeds dpkg up (very much so if the machine is memory-starved). -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Entries in Packages files that lack a Source field
On 20050519T205101+1000, Anthony Towns wrote:
> Something equivalent to:
>
> cat /var/lib/dpkg/available |
> awk '/^Package:/ {P=$2;V=""}
> /^Version:/ {if (V=="") { V=$2; } }
> /^Source: .* (.*)/ {V=substr($3,2,length($3)-2)}
> /^Source:/ {P=$2}
> /^$/ { print "Source-Package:", P; print "Source-Version:", V }
> {print}'
>
> I would've thought. (That adds "Source-Package:" and "Source-Version:"
> fields to every stanza)
>
> The idea being that "grep-available --source-info [...]" would work the
> same as piping the above into "| grep-ctrl [...]".
Any user can already put that in their ~/.grep-dctrlrc (well, a not
*literally* that, but instructions to that effect).
If someone wants it as a standard feature, feel free to wishlist-bug
grep-dctrl.
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
signature.asc
Description: Digital signature
Re: Entries in Packages files that lack a Source field
On 20050519T153811+1000, Anthony Towns wrote: > Adeodato Simó wrote: > > As you probably know, entries in the Packages file only have a Source > > field if the name of the source package is different from the name of > > the binary package being described. This is an inconsistency that makes > > it a bit harder to massage this data, e.g. with grep-dctrl. > > Why not add a patch to grep-dctrl instead? What patch would that be? Grep-dctrl is able to handle that, it just becomes a little messy (search in Source, and if there is no Source, search in Package). The most one could do for grep-dctrl would be to add a shorthand option for that; is it worth the trouble? Hmm, actually, it might make sense to add support for predicate abstractions. Hmm. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Detecting the installed MTA
On 20050407T172533+0300, Antti-Juhani Kaijanaho wrote: > (Don't use grep-status or grep-available in package scripts.) Since I've been asked, here's some more about that from /usr/share/doc/grep-dctrl/Compatibility : 8<-- If you use grep-dctrl in a Debian package, you should depend on the grep-dctrl package and heed the following compatibility notes: * Always call only the "grep-dctrl" executable. Although the "grep-status" and "grep-available" symlinks are installed by default, this may change in the future. Those symlinks are meant for manual - not scripted - use. * Always specify an explicit file name Don't rely on the implicit file name feature. The system administrator may have changed the default file name. * Not all features have been with us in every version Check if any of the features you use is mentioned in the changelog. Use a versioned dependency on grep-dctrl, if it is necessary. 8<-- The same information used to be included in the manual page, but it seems to have been dropped. I just uploaded 2.1.10 which reinserts the warning. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Detecting the installed MTA
On 20050407T153710+0200, Christoph Berg wrote: > Re: Søren Boll Overgaard in <[EMAIL PROTECTED]> > > During packaging, that is, during the installation of a package, I need to [...] > grep-status -FProvides mail-transport-agent | grep-dctrl -FStatus installed > -sPackage -n grep-dctrl -FProvides mail-transport-agent -a -FStatus installed -sPackage -n \ /var/lib/dpkg/status (Don't use grep-status or grep-available in package scripts.) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Vancouver hierarchy - proposed terminology
On 20050315T215603+, Henning Makholm wrote: > (Or, as alternative alternative terminology: > Widespread -> "utlanning" > Narrowspread regular -> "framling" > Irregular-> "ramen" > Other unix-like OSes -> "varelse" > Microsoft Windows-> "djur" > ) Heh, seconded :) But in the Card original, these are all terminology for foreigners; don't we have any natives in Debian? -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050301T195602+0100, Frank Küster wrote: > Well, but why should a self-dependency be ever necessary? A self-dependency is an oxymoron, since a package cannot be simultaneously unconfigured and configured. For that reason, a self-dependency is always a no-op (as I wrote earlier, it is harmless but ugly). Circular dependencies, however, are sometimes necessary. A good example is the base system, where many of the packages need each other to configure; but that particular case is solved by the essential packages list. In most other cases, circular dependencies can be removed by refactoring the package set. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050301T144403+, Henning Makholm wrote: > Scripsit Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> > > On 20050301T122452+0100, Tollef Fog Heen wrote: > > >> apt invokes dpkg on the command line and due to maximum command line > >> length it sometimes is split in an unfortunate place. > > > I'll repeat what I wrote above: > > > Doesn't apt usually unpack all packages first and then configure them in > > one run, so that shouldn't matter? > > I will refrain from repeating what Tollef wrote, but read it again > anyway. Apt neither unpacks nor configures packages; it uses dpkg for > that. There is and was nothing wrong wrong with my reading comprehension; the problem was that we did not share a common set of assumptions. For me "apt unpacks" obviously means "apt tells dpkg to unpack" and "apt configures" obviously means "apt tells dpkg to configure"; it was also obvious to me that "apt configures in one run" means it calls dpkg --configure -a. My mistake was the last assumption: I have now checked source, and apt really does list the packages even in a configuration run, which indeed is a problem. Had someone corrected my false (implicit) assumption, this thread would have been a lot shorter. Alas, it wasn't: not one response I got addressed the real problem. Perhaps it'd be useful to assume that I can read and then look for ways I could have made a mistake in my mental model. Then again, I could have been more explicit in listing my assumptions. Oh well. This thread has demonstrated Wiio's law: Communication usually fails, except by accident. (http://www.cs.tut.fi/~jkorpela/wiio.html) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050301T122452+0100, Tollef Fog Heen wrote: > | > > Doesn't apt usually unpack all packages first and then configure them in > | > > one run, so that shouldn't matter? > | > > | > dpkg does the same thing > | > | So how does apt break it but using dpkg doesn't? > > apt invokes dpkg on the command line and due to maximum command line > length it sometimes is split in an unfortunate place. I'll repeat what I wrote above: Doesn't apt usually unpack all packages first and then configure them in one run, so that shouldn't matter? -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050228T204520+, Andrew Suffield wrote: > On Mon, Feb 28, 2005 at 09:49:41PM +0200, Antti-Juhani Kaijanaho wrote: > > On 20050228T164806+, Andrew Suffield wrote: > > > Unfortunately apt breaks the code. If you use dpkg directly it'll > > > work. If you use apt it'll pick a random and unpredictable starting > > > point. > > > > Doesn't apt usually unpack all packages first and then configure them in > > one run, so that shouldn't matter? > > dpkg does the same thing So how does apt break it but using dpkg doesn't? -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050228T164806+, Andrew Suffield wrote: > Unfortunately apt breaks the code. If you use dpkg directly it'll > work. If you use apt it'll pick a random and unpredictable starting > point. Doesn't apt usually unpack all packages first and then configure them in one run, so that shouldn't matter? (Of course, essential packages and stuff like that break this but...) -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: self-depending packages
On 20050227T214242+0100, Nicolas Boullis wrote: > My understanding is that a self-depending package must be configured > before it can be configured, which makes it unconfigurable, and hence > uninstallable. And I think the same reasoning can be applied to > circular dependencies. But Loic disagrees. Self-dependencies are harmless but ugly. Circular dependencies are sometimes (though very seldom) necessary (most of the time the same effect can be got from a -common package). Dpkg tries to break the cycle at the least problemous point, for example configuring a package with no postinst first. > Should a bug be filed against those packages? Minor severity at most, IMHO. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Verify debianhttp://www.perrier.eu.org/debian/voices/-devel@lists.debian.org for Francois.Mescam@onera.fr
On 20050214T071408+0100, Christian Perrier wrote: > Debian address first, his automated greylisting system automatically > answered and did so using the Reply-To field. Then it is broken. Automatic mails should be sent to the envelope sender, unless explicitly asked otherwise. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Dependencies on kernel-image-x.y [was: NPTL support in kernel 2.4 series]
On 20050124T180205+, Thaddeus H. Black wrote: > Antti-Juhani Kaijanaho writes, > > > A package description is equally visible. > > But is it equally machine parsable? If not, > is this unimportant? Machine-parsability is not useful if the semantics is misused. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Dependencies on kernel-image-x.y [was: NPTL support in kernel 2.4 series]
On 20050122T161110+0100, Martin Kittel wrote: > I would like to have some clarification on whether it is sensible to > declare a package dependency on kernel-image-x.y (e.g. kernel-image-2.6, > _not_ a full kernel version kernel-image-x.y.z) No, it's not. The job of a depends relation is to make sure that another package is installed so that your package can link to the library it contains, can refer to the files it contains or can execute binaries it contains. To make a depends on a kernel worth the while, you'd need to be able to either link to the kernel, cause the kernel to run or refer in some other way to the files a kernel package contains. You can't link to a kernel and you can't cause it to run (except in an emulator, and I doubt that'd be of any use to you). And in this particular case, you are not trying to access files in the kernel package. Therefore, a depends relation is not warranted. > 1) it explicitely and visibly states the dependency that is inherent in > the package The situation here is analoguous to the question whether an X installation should depend on fonts: such a dependency would document the dependency on inherent in X, yet we don't do that, because there are reasonable setups of X where the fonts are provided outside the packaging system's knowledge. A Suggests or Recommends brings the same documentation value as a Depends, and it will not force people to work around a packaging system artefact. > 2) the information the dependency provides is visible _before_ the > package is even downloaded A package description is equally visible. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Is debhelper build-essential?
On 20050113T040729+, Scott James Remnant wrote: > The stats: > > 8,920 source packages in Debian unstable main. > 8,254 declare a build-dependency on debhelper > > = 92% of packages build-depend on debhelper. > > Is that sufficient to declare it build-essential? This issue belongs to debian-policy. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Bug #277824; is the hotkeys maintainer dead?
14:33 given that there have been actual deaths among debian devels, i don't think it's a good idea to ask "is the hotkeys maintainer dead?". someday, someone asking a similar question will get the answer "yes". 14:33 ibid: It's happened with the kernel 14:34 oh? 14:34 "This maintainer hasn't answered any of my mails or taken my patches. Is he dead or something?" 14:34 "Yes. Helicopter accident" 14:34 ouch Quoted with permission of the participants: ibid Antti-Juhani Kaijanaho mjg59 Matthew Garrett -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
On 20041022T134825+0200, Jérôme Marant wrote: > Before "testing", the RM used to freeze unstable and people were > working on fixing bugs. There were pretest cycles with bug horizons, > and freezes were shorter. That's not true (unless you are talking about something that was ceased several years before testing became live, certainly before I started following Debian development in 1998). Before testing the RM used to fork unstable into a "frozen" distribution. Unstable was still open for development, and heated arguments developed on this very list asking that the process be changed so that unstable would be frozen; this was never done. I don't know what you mean by "pretest cycles with bug horizons". The current freeze has been quite short - if one ignores the current delay by the missing testing security support - and pre-testing freezes were not that much shorter (unless, again, one looks at ancient history. when Debian was a lot smaller). > Instead of always telling than a given idea won't work, let's > try it and conclude afterwards. The problem is that on this scale trying such things out is costly and time-consuming. Arguably were are still in the process of trying "testing". -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Do _not_ file massbugs without consulting debian-devel (Re: Bug#277210: package description typo(s) and the like)
On 20041019T134416+0200, Bill Allombert wrote: > Please cool down, if you compare with #268503, this one includes a > patch whereas the original did not, so it is not a duplicate but an > improvement. In other words, it is a duplicate report with a patch. The proper thing (with respect to this individual case) would have been to send the patch to #268503 without opening a new bug. > It seems this bug submitter has made much more effort toward quality bug > reports than the previous attempt at fixing typos so I see no point > flaming him. He was not flamed; he was being corrected about an important piece of Debian etiquette. > I dream to receive patch in bug reports. Sending 63 patches > do not really qualify as massive bug filling. The issue is not whether it was massive but whether it was a mass bug report. There is a difference: the latter is usually indicated when many bugs are opened on a similar issue against several package based on a (semi)automated search for a particular kind of bug in the Debian archive. > If you think it is a duplicate, you should merge them not close it > summarily, especially since this one include a patch. That is true. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: Building Debian Completely From Source
On 20031206T145904-0600, John Goerzen wrote: > Obviously gcc is the #1 example of this. However, gcc packages should > not need to depend on themselves; in our distribution, we tend to have > many different versions of gcc available, and any of them should be able > to build a newer gcc. Nevertheless, *some* gcc version must build-depend either on itself or on some gcc version that directly or indirectly build-depends on that version. Thus, multiple gcc versions do not fix the circular build-depends problem. > Nothing else in main comes to mind right now, though I'm sure there is > something else... Any self-hosting compiler. We have several. GHC is an example. > But for everything but the C compiler, I think that the build probably > should do the bootstrapping work itself wherever possible. Bootstrapping on every build is not a good idea. For most builds, it's wasted work, since most builds will have a previous version available. Furthermore, any bootstrapping build requires either a bootstrapping compiler (and most languages do not have that in Debian) or distributing a precompiled intermediate form (either C or assembly) that can be further processed at build time to yield a bootstrapping compiler (which IMHO is cheating - it's about as nice as distributing a bootstrapping compiler executable in the source package). -- Antti-Juhani Kaijanaho, Debian developer http://www.iki.fi/gaia/ signature.asc Description: Digital signature
Re: Building Debian Completely From Source
On 20031206T085705-0600, John Goerzen wrote: > Yeah, I have found some of those circular build-deps. I believe they > should be considered serious bugs if they aren't already. That's just > wrong. There are several good reasons for circular build-time dependencies. For example, every self-hosting compiler build-depends on itself (many of them can be bootstrapped, but I'm not sure we want to require bootstrapping on every build - and some require manual bootstrapping work). -- Antti-Juhani Kaijanaho, Debian developer http://www.iki.fi/gaia/ signature.asc Description: Digital signature
Re: Bits from the RM
On 20031201T144509+1000, Anthony Towns wrote: > * #208646 - grep-dctrl - Antti-Juhani Kaijanaho > unspecified problems with version in unstable, should take > "a couple of days" to fix, no activity since September The "unspecified problems" are mainly recorded in the other open bugs against that package. The main issue is that the rewrite is not yet as good quality-wise as the old version (which is in testing), and thus I'd prefer to release the old version instead of the new one unless I am able to fix the new one in time. The current unstable version probably does not belong in unstable according to the "new" definition of what unstable is, but the rewrite went in a week or two before the new definition was published, and I haven't had the energy to arrange having the old version again in unstable and then uploading the new one to experimental (when I have that kind of energy, I'd prefer to put it to fixing the new package). That said, it has been too long since I last looked at grep-dctrl. I'll try to fix that "in a couple of days" :) I can only say that my teaching duties have exhausted me during the autumn. -- Antti-Juhani Kaijanaho, Debian developer http://www.iki.fi/gaia/ signature.asc Description: Digital signature
Re: [grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
On 20030428T093754-0400, Matt Zimmerman wrote: > As long as you take pleasure in continuing to maintain it in the future. ;-) I intend to :-) One of the reasons for this rewrite is to take care of the bit rot in the old sources (which was, thanks to the feature creep, quite considerable considering the size of the thing) and to make this more maintainable. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpfLCNv9H24t.pgp Description: PGP signature
Re: [grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
On 20030427T170110-0700, Joshua Kwan wrote: > I even used my own user account on the system and it doesn't have > permissions to write a cvs lockfile. Got a tarball? :( http://people.debian.org/~ajk/dctrl-tools_rewrite_snapshot_01.tar.gz This is the same set of files as in CVS tag rewrite_snapshot_01. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgps7X6d0spZe.pgp Description: PGP signature
Re: [grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
On 20030427T201013-0400, Matt Zimmerman wrote: > I had toyed with the idea of rewriting grep-dctrl using sgrep macros. I > haven't tried it, but I think it may be powerful enough. Did you look into > this possibility? No, I didn't. You are of course welcome to try, but I am not very interested in trying. There are also a number of other implementation mechanisms I didn't seriously consider (such as using Perl or Python, or making grep-dctrl a wrapper for ara:-). I take pleasure in writing this code (in addition to producing a useful piece of software, it allows me to learn and relax). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpdHIXkG4Iu6.pgp Description: PGP signature
[grep-dctrl] Testers requested - sneak preview of a full rewrite (better and faster!)
Hi, I am in the process of rewriting grep-dctrl. The rewrite attempts to gain speed over the old version while removing one of the greatest defects in the old code: the new grep-dctrl is able to combine searches in full boolean manner. The current version does not yet duplicate all the features of the old code, but most of the core functionality, as well as boolean queries, is implemented. In my own tests, the new code has beaten the old code speedwise in almost all situations and never lost to it. In some cases, I have seen as much as a sixfold increase in speed. I am requesting testers for the new code. Try all the stuff you are used to do with current grep-dctrl and verify that the old and the new code produce (essentially) identical output from identical inputs. Try out the new boolean search feature and try to find bugs in it. Try to find cases where the new code loses to the old code speedwise (or to the other options: dpkg. dpkg-awk, ara, maybe even apt-cache). Report your findings (both positive and negative) to me, at [EMAIL PROTECTED] Do not use the BTS for the new code yet. The following features of the old code is not yet functional: * The switches -n, -d, -c, -v, --config-file * Command name based input file location (thus, there is no grep-status or grep-available) * Multiple field names in -F (use the boolean query mechanism to get the effect) (I intend to fix this before this code goes to unstable. The new code will duplicate all the functionality of the old code, eventually.) The following new features are implemented: * Boolean queries: use -a (--and), -o (--or), ! (--not); parentheses can be used like in test or expr For example -F Section utils -a ! -FDepends -e 'gnome|kde|gtk' The new code is not yet packaged, you need to compile it out of cvs. It is in Alioth, project dctrl-tools, branch v1_rewrite: cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/dctrl-tools co \ -r v1_rewrite dctrl-tools make (The debian/ directory there is out of date, and so are the docs.) Thank you all for your attention. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgp9jIbyJ1abX.pgp Description: PGP signature
Re: i386 compatibility & libstdc++
On 20030425T180852+0200, Emile van Bergen wrote: > The problem is STL ... or rather, its abuse. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Taiteellisen ohjelmoinnin ystävien seura Toys - Ohjelmointi on myös taidetta http://www.cc.jyu.fi/yhd/toys/ pgpmtVLKonz7Y.pgp Description: PGP signature
green-card to be removed from distribution
retitle 82597 O: green-card -- A foreign function interface preprocessor for Haskell thanks If there is nobody who'll take this package, I'll ask for its removal from the distribution. (It does not compile from source currently so I can't just orphan it in the normal way.) You have one week to take this package (please make an upload!), if you want to keep it in Debian. -- Antti-Juhani Kaijanaho, LuK (BSc)* http://www.iki.fi/gaia/ * [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: at least 260 packages broken on arm, powerpc and s390 due to wrong assumption on char signedness
On 20011227T200851+0100, Gerhard Tonn wrote: > I grepped my archived build logs and found that all packages below have got > this problem. Bzzz, wrong assumption. You should have read the code. The warning you cite can be the result of other problems, and it also can be a non-problem. The last is the case with catdvi, which your list includes. The line in catdvi that gets this warning is if ((b >= DVI_set_char_0) && (b <= DVI_set_char_127)) Now, DVI_set_char_0 happens to be defined as 0, and I could have in principle omitted the test, but I prefer this formulation as it is IMHO clearer. In the above code, b is declared as a "byte", which is in turn a typedef for unsigned char. -- Antti-Juhani Kaijanaho, LuK (BSc)* http://www.iki.fi/gaia/ * [EMAIL PROTECTED] assistentti (ohjelmistotekniikka) / assistant in software engineering Jyväskylän yliopisto, tietotekniikan laitos University of Jyväskylä, Department of Mathematical Information Technology
Re: How many people need locales?
On 20010903T022104+0200, Santiago Vila wrote: > [ See Bug #111008 for details ]. Looking at that bug, you are asking the wrong question. You should be asking about the need for localized messages, not about the need for locales. Most Finnish users use the fi_FI locale, but many still use English messages due to the perceived badness of the translations. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: Developer Behavior
On 20010108T084511-0800, Aaron Lehmann wrote: > The DAM is quite busy, and I sympathize with him. However, once > allowed to I would voulenteer to aid him with his duties to expedite > the processes. I doubt that a fresh developer would be allowed to take on such a vulnerable position as the DAM. You'd have to be quite extraordinary to achieve that. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Keep the Deja Archive Alive! http://www2.PetitionOnline.com/dejanews/petition.html
Re: Postgres 7?
On 20010105T134204-0800, Luca Filipozzi wrote: > The creation of 'testing' has meant that all the packages in woody have > reverted to the versions from potato. Packages from unstable will migrate > to testing once all their dependencies are also in testing. ... and once they have been RC-bugless in unstable for some time (maximum minumum of 14 days). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: bugs + rant + constructive criticism (long)
On 20010103T212649-0600, Adam Heath wrote: > Perl is a required package, there is no need to list the dependency. That it is required is not relevant. That it is a virtual essential package is. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: bugs + rant + constructive criticism (long)
On 20010104T100704-0600, Steve Greenland wrote: > On 03-Jan-01, 22:53 (CST), John Galt <[EMAIL PROTECTED]> wrote: > > The difference between pine and mutt is that you KNOW the overflows in > > pinemutt allegedly shares code with pine... > > Extremely unlikely, as it originated from elm. Pine also originated from elm, so theoretically it's possible (although I think both are complete rewrites). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Re: List of packages that could be dropped
On 20001226T152221+0100, Christian Kurz wrote: > |malaga (210 days old) > > Has this package been dropped? No. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#71306: ITP: GZigZag -- An implementation of Ted Nelson's ZigZag
Package: wnpp Severity: wishlist I intend to package GZigZag, which is a Java implementation of Ted Nelson's ZigZag. A stable release is coming soon, and that's what I'll be packaging. ZigZag is a new way of putting information into computers, kind of a crossing between a database, a filesystem, a personal information manager and many others. And even that isn't sufficient to describe it: it's simply something new. The main point is the unifying ZigZag structure in which everything is in cells or in their dimension-based interconnections. The current version is in many senses a prototype or a preview, but many useful things can already be done with it (for example, presentations and managing your personal information). URL: http://gzigzag.sourceforge.net/ The package is dual-licensed as LGPL and XPL (Xanadu Public License). Debian will, of course, distribute it under the terms of the LGPL. The program compiles cleanly with Jikes, but since Kaffe has a nasty bug that makes GZigZag currently almost unusable with it, I'll be putting GZigZag in contrib for now. When the Kaffe bug is fixed, we'll move to main. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OT Re: /bin/ksh as a default POSIX shell
On 2906T033439-0500, Branden Robinson wrote: > On Tue, Sep 05, 2000 at 10:03:56AM +0200, Ulf Jaenicke-Roessler wrote: > > Saved to "branden.asc" and 'gpg -d branden.asc' results in > > > > gpg: CRC error; 72a653 - dc372a > > gpg: quoted printable character in armor - probably a buggy MTA has been > > used > > This concerns me a lot more than the joke itself or what led up to it. > > Does anyone else have this problem with that mail? If you save the message to a mailbox (s or C in mutt), the save will include QP. Likewise if you pipe (|) it to gpg. However, if you copy&paste it from mutt, it's OK. It's just that mutt does not QP-decode messages that it saves and pipes. > In fact, I'm gonna be mondo pissed no matter whose bug this is, let's try > and track it down. It's probably a pilot error. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla update in Potato Proposed updates?
On 2905T215159-0700, Frank Belew wrote: > If you have reasons why it shouldn't be in potato I'd like to know The question should be "why it should be in potato". Oldness of the current version is not a reason, since there are a lot of old packages in potato, and if one is let in for that reason, the others should be allowed too. And we all know what happens when stable is no longer stable (=not moving). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#70948: ITP: ifinnish-small, ifinnish-huge
Package: wnpp Severity: wishlist New versions of ispell-fi (binary packages wfinnish and ifinnish) have three sizes for the spelling dictionary: small, medium and large. Their differences are in the number of words and word forms recognized and in the disk space and memory requirements for ispell. I intend to create the binary packages ifinnish-small (containing the small dictionary) and ifinnish-huge (containing the large dictionary). The ifinnish package (which is recommended for most uses) will contain the medium-size dictionary. Upstream URL: http://ispell-fi.sourceforge.net/ -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libgd1 vs. libgd1g
On 2904T14+0200, Remco van de Meent wrote: > getting angry when you don't reply to their requests within one hour, > even if you are 'on leave' as stated on db.debian.org. Nondevelopers do not have access to the away information in db.d.o. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/ksh as a default POSIX shell
On 2903T152152-0500, Branden Robinson wrote: > -BEGIN PGP MESSAGE- ... > -END PGP MESSAGE- gpg: encrypted with 1024-bit ELG-E key, ID 22CC9EBE, created 2000-08-17 "Ulf Jaenicke-Roessler <[EMAIL PROTECTED]>" gpg: no secret key for decryption available gpg: decryption failed: secret key not available Um, why send such a message to a widely-read mailing-list? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: moving packages to project/orphaned
On 2903T125642-0700, William Lee Irwin III wrote: > On Sun, Sep 03, 2000 at 06:55:16PM +0200, Marcelo E. Magallon wrote: > > The follwing packages need a new maintainer: > > hugs (68186), 33 days old > > hugs-doc (68187), 33 days old > > I was under the impression that I was taking care of these two > (although I haven't done much with them. Tony Mancill is my sponsor in > all that. If there is a pressing need to fix something about these two > I can probably handle it. Well, they'll be in that list until you actually take them over. An upload with changed Maintainer address is sufficient. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 2901T104626-0500, Steve Greenland wrote: > find. The policy manual says look in build-essential. The control > file for Build-essential says look in policy manual The policy manual says look for the *informational* list in build-essential. build-essential says look for the *definition* in the policy manual. I don't see the problem. > and includes two > different list files, one of which is completely pointless, the other of > which has the needed info buried in the middle of a bunch of definitions > and syntax. I wonder why I haven't seen a bug report from you about this. > Just put the list on the > website, It is in the website, starting yesterday. > Why are people determined to make information so hard to find? Why are people determined to make pointless rants instead of filing useful bugs? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#70269: automatic build fails for potato
On 2830T234249+0100, Julian Gilbey wrote: > On Wed, Aug 30, 2000 at 01:06:30PM -0500, Steve Greenland wrote: > > Which is just a stupid pain in the ass. I had to track through three > > different references and finally install the "build-depends" package to > > find out what I could leave out of by "Build-Depends" stanza. It would > > *much* easier for developers, if less ideologically pure, to just list > > the damn packages on the Developers Corner part of the website. > > Could we add this as a footnote to the relevant section in policy or > the packaging manual (can't remember which offhand)? Um, the current note in policy manual is not sufficient? (It explicitly mentions the package "build-essential".) -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
Bug#70634: Typo in policy manual
Package: debian-policy
Version: 3.2.1.0
On 2830T184956-0400, Matt Zimmerman wrote:
> On Wed, Aug 30, 2000 at 08:51:47PM +0300, Antti-Juhani Kaijanaho wrote:
>
> > The definition is the following:
> >
> > It is not be necessary to explicitly specify build-time relationships
> > on a minimal set of packages that are always needed to compile, link
> > and put in a Debian package a standard "Hello World!" program written
> > in C or C++. The required packages are called _build-essential_, and
> > an informational list can be found in
> > `/usr/share/doc/build-essential/list' (which is contained in the
> > `build-essential' package).
> >
> > (Debian Policy v. 3.2.1.0, section 2.4.2.)
>
> I can't find a bug open regarding the obvious grammatical error at the
> beginning of this paragraph ("It is not be"). Is someone aware of it
> nonetheless?
>
> I imagine it should read "It is not necessary...".
>
> --
> - mdz
Why didn't you file the bug then?
(I believe it originally said "it will not be" and then somebody
edited it.)
Bug#70603: Can we please list build-essential packages in Developer's Corner?
Package: www.debian.org Severity: wishlist On 2830T130630-0500, Steve Greenland wrote: > find out what I could leave out of by "Build-Depends" stanza. It would > *much* easier for developers, if less ideologically pure, to just list > the damn packages on the Developers Corner part of the website. Well, since Developer's Corner is not Policy, we can make that happen. Webmasters, can we get some arrangement such that the informational list of build-essential packages (see the package build-essential) is available in the Developer's Corner, preferably automatically updated from the package? -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Hypertekstivisionääri Ted Nelson luennoi Jyväskylässä 29.-31.8. Lisätietoja saa minulta.
