For those who care about pam-ssh: RFC
I have recently adopted the libpam-ssh package and made a lot changes in the way the PAM module works. In summary, the module did not work as advertised, so I rewrote parts of it while trying to make as little disruption as possible, but one cannot make an omelet... Because of the security implications of changing a PAM module, I would welcome some peer reviewing of the changes I have made. The new package has been uploaded to experimental, and the NEWS.Debian is as follows. Also, I would like comments in general about the whether there are better ways to solve the problems. * The PAM modules are now named 'ssh_auth' and 'ssh_session' which seems to be more in line with other PAM modules' names. * The 'keyfiles' option is now obsolete. Instead the authentication module will automatically locate all files matching the pattern 'id_*' (the idea for this came from a patch from Javier Serrano Polo). * The 'try_first_pass' now works as advertised, namely by asking for an SSH passphrase if the password from the previous PAM module fails to unlock any of the user's SSH keys. * The 'debug' option now works as advertised, and the output goes into /var/log/auth.log . * No SSH passphrase will be asked if the user has no SSH keys. Thanks in advance, /JP -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? pgpw63HSg0q5y.pgp Description: PGP signature
Re: For those who care about pam-ssh: RFC
2008/12/4 Vincent Zweije <[EMAIL PROTECTED]>: > On Thu, Dec 04, 2008 at 02:03:52AM -0800, Steve Langasek wrote: > > || On Wed, Dec 03, 2008 at 11:19:52PM +0100, Jens Peter Secher wrote: > || > || > * The 'keyfiles' option is now obsolete. Instead the authentication > || > module will automatically locate all files matching the pattern > 'id_*' > || > (the idea for this came from a patch from Javier Serrano Polo). > || > || That doesn't sound like a good idea to me. What if a user has extra ssh > || keys lying around that multiple people have the passphrase to, which prior > || to this change would have been perfectly safe? > || > || Also, why is the pattern id_*? ssh also recognizes 'identity' by default. > || Shouldn't this really use the same pattern as ssh itself, i.e., > || (identity|id_dsa|id_rsa)? > > In addition I, and probably some others, have the habit of disabling > files by adding a .OFF extension to it. > > This practice is based on the (in my view) reasonable assumption that > programs should not be scanning directories for files to use unless > those directories are specially intended for that purpose. > > It probably would be fine if there were a (documented) ~/.ssh/id.d/ > directory containing keys to be used (and nothing else). > That is a very good idea. But the id.d directory should probably contain soft links to the actual keys to not interfere with the standard location. Are the other packages which does something similar? If there are no objections, I will implement such a behaviour. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about pam-ssh: RFC
2008/12/4 Luca Niccoli <[EMAIL PROTECTED]>: > 2008/12/3 Jens Peter Secher <[EMAIL PROTECTED]>: > >> Because of the security implications of changing a PAM module, I would >> welcome some peer reviewing of the changes I have made. The new package >> has been uploaded to experimental, and the NEWS.Debian is as follows. >> Also, I would like comments in general about the whether there are >> better ways to solve the problems. > > As a user, I see a regression: I have @include (pam)-ssh-auth before > @include common-auth in my confguration, and I use two different > passwords for my local account and my ssh key; this way if I know > I'll be networking I take the bother to type the long-and-very-secure > password to unlock my key and get acces to the computer, otherwise I > just hit enter and I'm asked for the simpler local password To do that you will need to change /etc/pam.d/ssh-auth to auth sufficient pam_ssh.so such that the SSH passphrase is always asked, and, if it unlocks any of the SSH keys, it will be sufficient to login. > (I don't > think there's really a point in a strong password if someone has > physical access to the computer). Hmm, if noone else has access to the computer (including remote access) then the passphrase on the SSH keys do not need to be more secure than the login password. On the other hand, if there is remote access to the computer, then a weak password will enable an evil hacker to get into you account, copy your SSH key and brute-force attack the key elsewhere. So I do not really see your point. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about pam-ssh: RFC
2008/12/4 Luca Niccoli <[EMAIL PROTECTED]>:
> 2008/12/4 Jens Peter Secher <[EMAIL PROTECTED]>:
>
>> To do that you will need to change /etc/pam.d/ssh-auth to
>>
>> auth sufficient pam_ssh.so
>
> I know, that's why I'm not complaining =)
> May writing it in the README.Debian could be a good idea.
>
OK, will do.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about pam-ssh: RFC
2008/12/5 Peter Palfrader <[EMAIL PROTECTED]>:
>
> It should probably also be called something that describes its purpose
> accurately. like login-keys.d or pam-key.d or something like that.
> id.d is just too generic.
OK, I will use ~/.ssh/login-keys.d, unless there are objections.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about pam-ssh: RFC
2008/12/6 Allan Wind :
> On 2008-12-03T23:19:52, Jens Peter Secher wrote:
>> * No SSH passphrase will be asked if the user has no SSH keys.
>
> Is the idea to make the module optional if there is no private key? It
> would be fine if the module is configured as optional (and perhaps
> sufficient?), but if the module is required then it leaks if the key
> exist and possible if the user exist or not.
>
I have changed the behaviour so that: if the user has no keys, then it
results in an immediate failure only when the try_first_pass option is
used.
Also, if the user does not exist, then an SSH passphrase is asked
anyway, which should fix the information leak.
The package version is libpam-ssh_1.92-3 in experimental. I have
tested it extensively, but there is an awful number of ways to use the
module, so I might have missed something. Please help me and give it
some real-life testing. :-)
Thanks in advance,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
2008/12/15 Luca Niccoli :
> If I type a non-existent user name, I'm asked the SSH password anyway...
That is intentional to make it harder to tell the difference between
which users exist and which do not.
> My /etc/pam.d/gdm
>
> #%PAM-1.0
> authrequisite pam_nologin.so
> authrequiredpam_env.so readenv=1
> authrequiredpam_env.so readenv=1 envfile=/etc/default/locale
> auth sufficient pam_ssh.so try_first_pass
> @include common-auth
Using option 'try_first_pass' does not make any difference when no
previous module has asked for a password.
> authoptionalpam_gnome_keyring.so
Ahh, Gnome Keyring.
Sorry that I did not make this clear. All the development and testing
I have done is on a simple system without any other keyring or agent
stuff, and only through /etc/pam.d/login to make sure the basics are
working. If you find something that is not working in such a basic
environment, you should try to add the 'debug' option to pam_ssh and
watch /var/log/auth.log.
I have not yet dived into Gnome Keyring but I will when I am sure that
the basics are up and running.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For those who care about pam-ssh: RFC
2008/12/17 Steve McIntyre :
> Luca wrote:
>>2008/12/16 Luca Niccoli :
>>
>>++file_filter(const struct dirent *dir)
>>++{
>>++ return (DT_REG == (DT_REG & dir->d_type)) ||
>>++ (DT_LNK == (DT_LNK & dir->d_type)) ;
>>++}
>>
>>But I use XFS, which seems to have some problems with d_type [1]
>>I'm not really sure this is the source of the problem, but I thought
>>it was worth giving a try...
>
> I don't know about the exact state today, but at least in the past
> many filesystems have not filled in d_type in readdir() calls. If you
> want to see the type of a filesystem object safely and portably,
> you'll need to call stat() or similar on each file.
I have uploaded libpam-ssh_1.92-4 to experimental which stat's the SSH
keys directly. Unfortunately I have not had the time to test it on an
actual XFS system.
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: pbuilder build with passing -sa option
On 17/11/2007, Piotr Roszatycki <[EMAIL PROTECTED]> wrote:
> I give up. I really don't know how to pass "-sa" option to
> dpkg-buildpackage when I use
>
> pbuilder build *.dsc
I use eg.
pdebuild --configfile ~/debian/stable-pbuilderrc --debbuildopts '-sa -v1.5-1'
when doing backports.
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Portability links in library and development packages?
Let us say I have packages libfoo++1 and libfoo++-dev which make standard files
/usr/lib/libfoo++.so.1.0.0
/usr/lib/libfoo++.so.1 -> libfoo++.so.1.0.0
and
/usr/lib/libfoo++.a
/usr/lib/libfoo++.la
/usr/lib/libfoo++.so --> libfoo++.so.1.0.0
/usr/include/foo++/
Now, in some other distributions, these files are called foopp instead
of foo++, and so to aid portability of client code, I put in the
additional following links.
/usr/lib/libfoopp.so.1 -> libfoo++.so.1
and
/usr/lib/libfoopp.a --> libfoo++.a
/usr/lib/libfoopp.la --> libfoo++.a
/usr/lib/libfoopp.so --> libfoo++.so
/usr/include/foopp --> foo++
I have a funny feeling that such links could break something, but I
cannot find a case where it actually does. Can any of you?
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebuilding the archive in a dirty chroot: results
On 25/01/2008, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> I've done two rebuilds of sid on i386.
[...]
> - one in a chroot, where as many build-dependancies as impossible were
> installed (take the Sources file, extract the build-deps for all
> packages, and install as many packages as possible) (the chroot is
> named bdfh -- build daemon from hell)
In the failed BDFH build
http://people.debian.org/~lucas/logs/2008/01/22/bdfh/logs/haxe_1:1.17-1_sid32-bdfh.buildlog
, I can see
/usr/lib64/libz.so.1: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
Error during linking
Error while running ocamlopt -o ../bin/haxe ../ocaml/extLib.cmxa
../ocaml/extc/extc.cmxa ../ocaml/swflib/swflib.cmxa
../ocaml/xml-light/xml-light.cmxa unix.cmxa plugin.cmx ast.cmx
lexer.cmx parser.cmx type.cmx transform.cmx typer.cmx genswf9.cmx
genswf8.cmx genswf.cmx ../neko/libs/include/ocaml/nast.cmx
../neko/libs/include/ocaml/nxml.cmx
../neko/libs/include/ocaml/binast.cmx genneko.cmx genxml.cmx genjs.cmx
genas3.cmx main.cmx
It looks like something is trying to use a 64bit library on a 32bit
macine, and it looks like it is the OCaml compiler.
So my question is, have others spotted similar problems, and if so in
connection with Ocaml?
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469993: ITP: siggen -- Waveform generation tools
Package: wnpp Owner: Jens Peter Secher <[EMAIL PROTECTED]> Severity: wishlist * Package name: siggen Version : 2.3.9 Upstream Author : Jim Jackson * URL or Web page : http://www.comp.leeds.ac.uk/jj/linux/siggen.html * License : GPL v2 Description : Waveform generation tools a set of tools for imitating a laboratory Signal Generator, generating audio signals out of Linux's /dev/dsp audio device. There is support for mono and/or stereo and 8 or 16 bit samples. The tools include: . * soundinfo: display some of the programming capabilities of the sound system support for the mixer device /dev/mixer and the DSP device. Also shows some of the ioctl calls in action. . * sgen: a command line signal generator where details are specified from the command line for generating sine, cos, square, triangle, sawtooth, pulse, noise waves. Frequency, sample rate, relative amplitude etc. can be specified through command line options. The signal is played continuously until the program is stopped. There are options to save the basic raw digital samples raw to file or to a WAVE format file. . * swgen: a command line sweep generator. Both the sweeping and swept waveforms can be specified, along with the sweeping frequency and the swept frequency range. Otherwise similar to sgen above. . * siggen: an Ncurses screen based Signal Generator for two separate channels. On stereo audio cards the two channels are played on separate outputs. On mono cards the teo channels are digitally mixed onto the one output. Type of waveform, frequency, amplitude, sample rate etc are specified/changed via a screen menu. It plays continuously. Changes to parameters take effect nearly immediately. . * sweepgen: an Ncurses screen based Sweep generator (see swgen and siggen above). . * tones: a command line program to generate several successive tones of varying frequency, and optional differing waveforms, durations and intensities. The sequence of tones can be either played once, or repetitively or the samples can be written to a file in raw or WAV format. This could make the basis of an auto-dialer for tone phones. . * smix: a simple command line program for getting and setting the mixer settings. . * fsynth: an Ncurses based fourier synthesis realtime generator. I will put an initial package on http://people.debian.org/~jps . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)
Steve Langasek <[EMAIL PROTECTED]> writes:
> Below is a list of libraries which appear to be blocking other packages that
> need to go through the C++ transition[1] and which are themselves ready to
> go through the ABI transition.
[...]
> libcrypto++
I am fighting with libcrypto++ but so far I am loosing.
GCC4 does definitely not like a mix of templates and anonymous enums
[1,2] but there are easy fixes for this.
What is worse, it seems that GCC4 silently refuses to generate code for
some template instantiations, which results in undefined symbols in the
library, as others have experienced [3]. It might however be the case
that GCC4, being more C++ standards compliant, has simply revealed a
problem in the Crypto++ template code.
In any case, the fact is that the non-debian, clean upstream library
code (5.2.1) compiles and links fine with GCC3, but fails to do so with
GCC4. I am still investigating...
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318518
[3] http://www.mail-archive.com/cryptopp-list@eskimo.com/msg02236.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcrypto++
Florian Weimer <[EMAIL PROTECTED]> writes:
> There's another problem with libtool:
>
> [...]
> ./libtool: line 4120: test: : integer expression expected
> ./libtool: line 4120: test: : integer expression expected
> creating reloadable object files...
> ./libtool: line 4154: test: : integer expression expected
> ./libtool: line 4154: test: : integer expression expected
> [...]
>
> After that, libtool performs linking with quadratic complexity:
Hmm, strange, I do not get that with libtool 1.5.6-6 on an i386.
> This means that I'm probably not able to test my patch, which is
> included below.
I tried out your patch, but still get the same linking error, that is,
undefined symbols. But thanks for the leads.
Cheers,
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/gconf/gconf.xml.defaults/ --- Why /etc ?
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> [ Complain about useless/unnecessary differences in Gnome /etc file. ]
> The "schema" field does not look like configuration, either. In short,
> these files don't seem to be configuration files at all. Some of these
> files apparently contain localizations, too. Once again, not
> configuration.
>
> It produced nearly 70,000 lines of diff. That is quite frankly
> ridiculous. Maybe there is some configuration data in there *somewhere*,
> but I sure am not going to spend the time to read 70,000 lines to find them.
>
> Please, could someone tell me why these should not be in
> /usr/share/gconf? Otherwise, I propose a mass bug filing.
I wholeheartedly agree with this. When a system administrator tries to
get an overview of system changes or upgrades, there is just too much
noise in /etc. As an effect of this, I have had to special-case Gnome
files in /etc in the changetrack package so that these files are
ignored, which is obviously not ideal.
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: neko -- High-level dynamically typed programming language
Package: wnpp
Owner: Jens Peter Secher <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: neko
Version : 1.5
Upstream Author : Nicolas Cannasse (Motion-Twin)
* URL or Web page : http://nekovm.org
* License : LGPL
Description : High-level dynamically typed programming language and VM
Neko has been designed to provide a common runtime for several
different languages, including JavaScript and haXe.
.
The compiler converts a source file (.neko) into a bytecode file (.n)
that can be executed with the Virtual Machine. You can use the
compiler as standalone commandline executable separated from the VM,
or as a Neko library to perform compile-and-run for interactive
languages.
.
The virtual machine is both very lightweight and well optimized. It
can be easily embedded into other applications, and libraries are
directly accessible using the C foreign function interface.
I have a neko package ready which includes the Apache 1.3/2.2 modules
mod_neko / mod_neko2. But I would like the Apache modules integrated
properly with the Debian Apache setup.
My plans are to produce two additional packages, libapache-modneko and
libapache2-modneko, like:
Package: libapache2-modneko
Architecture: any
Section: web
Depends: neko (= ${Source-Version}), apache2 (>> 2.2)
Description: Apache module for running Neko programs
Neko is a very lightweight and well optimized virtual machine. With
this module you can dynamically generate server-side web pages from
Apache.
First question: Is it called for to have two such libapache{,2}-modneko
packages, or should I simply include the mod_neko{,2} in the neko
package and test postinst whether there is an Apache installed and if so
do the proper Apache module setup?
And what is the proper Apache setup? I have googled my way to some
incomplete pages about how Apache modules should be set up in Debian,
searched through the /usr/share/doc/apache* files, and I have looked at
an existing Apache module package (modxslt) to see if I could grok the
setup, but I cannot really say I understand what goes where and why.
Is there an official policy or step-by-step guide somewhere?
Cheers,
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
PS: Sorry to not having sent this message directly
[EMAIL PROTECTED] with the proper pseudo-headers, but when I try
that I get a 550.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I am off-line January 10th-26th
If there are serious problems in the packages I maintain, then simply make an NMU. (Since I am not an official developer, I send this here. Sorry for the bother.) -- Jens Peter Secher _ [EMAIL PROTECTED] - http://www.diku.dk/~jpsecher - (+45) 35 32 14 08 _OpenPGP fingerprint dd6a 05b0 174e bfb2 d4d9 b52e 0ee5 978a fe63 e8a1_
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
2009/5/6 Josselin Mouette :
> Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit :
>> Maybe we should also consider changing the default MTA to postfix?
>
> Given that the default configuration is extremely simplistic and doesn’t
> use a percent of either exim or postfix features, I still wonder why it
> is not something like nullmailer or ssmtp.
>
+1 for ssmtp
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts output wishlist?
2009/6/20 Lars Wirzenius :
>
> I'm thinking about changing the way piuparts outputs results. At the
> moment it outputs a log file that contains everything it does, and
> buried deep in that is the test results. This tends to work badly.
[...]
> How would _you_ like to see piuparts report results, and produce other
> output? Go wild, the sky is bright blue.
I: Reading database ... 5834 files and directories currently installed.
I: Removing bla bla ...
I: Purging bla bla ...
W: Suspicious action bla bla ...
E: dpkg: error processing ucf (--remove)
E: bla bla...
Alternatively
[I] Reading database ... 5834 files and directories currently installed.
[I] Removing bla bla ...
[I] Purging bla bla ...
[W] Suspicious action bla bla ...
[E] dpkg: error processing ucf (--remove)
[E] bla bla...
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
OT: macs?
martin f krafft <[EMAIL PROTECTED]> writes:
> "a mac is like a prostitute. sure they look good,
> but your wallet will feel a lot lighter after getting one."
Shouldn't that be
"Windows is like a prostitute. Sure it's got a nice make up,
but you have all kinds of vira after spending some time with it."
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher get2net dk_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
HPPA, Arm, or M68k with g++ >= 4:4.0.2-2 ?
I need to test that a package can be built with g++ >= 4:4.0.2-2 on HPPA, Arm, or M68k. Is there a DD accessible machine that has a current version of g++ installed? Cheers, /JP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: soname number in name of dev-package?
Anthony Towns writes:
> Frank Küster wrote:
>
> > Do I understand right that you recommend not to use libfoo1-dev,
> > libfoo2-dev generally, but that the most recent version should be just
> > libfoo-dev? The Debian library packaging guide gives the opposite
> > advice, to use libfoo-dev always, but I have learned that this
> > document does not represent a consensus, anyway.
>
> If you need libfoo-dev 1 and libfoo-dev 2 installed simultaneously on
> user's machines, you need different package names. That's desirable
> very rarely and usually entirely undesirable -- it wastes disk space,
> forces people to edit build-depends and potentially makefiles, and
> generally ends up just being confusing.
But the advice in the library packaging guide is to do something like
Package: libpackage2-dev
Provides: libpackage-dev
Conflicts: libpackage-dev
which means that only one of the -dev packages can be installed on any
one system.
AFAICT the above approach offers nothing more than simply
Package: libpackage-dev
would do. Right?
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher get2net dk_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: soname number in name of dev-package?
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Jens Peter Secher <[EMAIL PROTECTED]> > > > But the advice in the library packaging guide is to do something like > > Package: libpackage2-dev > > Provides: libpackage-dev > > Conflicts: libpackage-dev > > AFAICT the above approach offers nothing more than simply > > Package: libpackage-dev > > would do. Right? > > If the source-level API differs, then having libpackage2-dev will > allow other packages to Build-Depend on the API they are written > against. Of course this is especially relevant when the API change can > make things break silently, but even outside that case, an explicit > build-dependency is easier to diagnose (and/or search for mechanically > over all packages in testing, say) than sudden compiler failures. But that problem could just as well be solved by versioned build-dependency on the -dev package, right? -- Jens Peter Secher _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher get2net dk_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: copyright vs. license
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Andrew Suffield <[EMAIL PROTECTED]> writes:
>
>> It's not required. And I get bored by updating them.
>
> Yes, the year is required, and moreover, you need to add a new year
> every time there is a new publication in a year not already mentioned
> (without removing the old years, since the new publication is a
> derived work).
And remember that you need to brush your teeth before you go to bed.
--
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher get2net dk_
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG signing of debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Metzler wrote: > - I personally always run dpkg-buildpackage with -uc -us and use > debsign -kkeyid foo_changes to sign the /final/ packages > afterwards. I usually build the packages more than once before > uploading as I often find some last-minute bug, and don't like to > type in my gpg-passphrase more frequently than necessary. Or alternatively install quintuple-agent and then have a script say ~/bin/adebuild like #!/bin/sh if [ ! -n "$AGENT_SOCKET" ]; then eval `q-agent &` fi if [ -n "$AGENT_SOCKET" ]; then debuild --linda -eAGENT_SOCKET -pagpg -sgpg $* else echo Quintuple agent not found. Using standard debuild. debuild $* fi to build your package. Then you only have to type your password once. But of course, what you really should do is use pdebuild to make sure your package will build on a clean sid system. Cheers, /JP -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQTR7DuWXiv5j6KERAv/jAJ4jsu7PIeVztm9EV9xqOMUxGCz98gCgtmY6 Ont4aeVir3ut/VfCSyCxs54= =kdL+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365425: ITP: haxe -- Web programming languge generating Flash SWF
Package: wnpp Severity: wishlist * Package name: haxe Version : 0.b5 Upstream Author : Nicolas Cannasse * URL or Web page : http://haxe.org * License : GPL Description : Web programming languge generating Flash SWF haXe is a programming language similar to JavaScript, but with full-featured type system and generics. The compiler can generate Flash SWF files for client-side use, and Neko bytecode for server-side use on Apache. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Depends vs. Recommends (Was: Bug#378112: ITP: gzrt -- gzip recovery toolkit)
Adam Borowski <[EMAIL PROTECTED]> writes: > On Sun, Jul 16, 2006 at 10:11:41AM +0200, Thijs Kinkhorst wrote: >> >> I agree that that is a common type of file to recover, so that would >> make it more appropriate to Recommend cpio rather than Suggest. > > "a common type"? Come on, that's not just "common", it's "a vast > majority of cases". And, a hard Depend on a small priority=important > package is not a big burden -- what about just having a dependency > without the comment? No. And the reason can be found in Policy section 7.2: 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. The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be present in order to run. Note, however, that the postrm cannot rely on any non-essential packages to be present during the purge phase. Recommends This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. The dependency system is used to make sure things don't break on the _system_ level. To ease upgrades, transitions, etc., dependencies (Depends) should be kept to the absolute minimum. Cheers, -- Jens Peter Secher _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_ A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: trayer_1.1_i386.changes REJECTED
2009/9/2 Torsten Werner :
>
> why is it a native package? Why do we need this package in Debian that got
> removed recently from unstable? I would expect an explanation either in bug
> #541265 or in the changelog.
>From the changelog:
* Upstream has abandoned the program, so the package is now Debian
native.
>From http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=541265
reopen 541265 j...@debian.org
thanks
> "Personally, I would drop the package entirely, it's unsupported and
> there's a better alternative already, called stalonetray
> http://stalonetray.sourceforge.net/, it's also available in Debian."
> (Maciej Delmanowski)
Except that stalonetray does not work, at least not together xmonad. I
will probably file bugs against stalonetray later.
In the meantimem, I am willing to maintain trayer.
And I will add to that that trayer has 500+ installations according to popcon.
>
> missing copyright info; some examples:
>
> systray/eggtraymanager.c
> Copyright (C) 2002 Anders Carlsson
>
Well, I noticed some missing copyrights in the old package, so added
this to the debian/copyright:
systray/fixedtip.{c,h}: Copyright (C) 2001 Havoc Pennington
systray/eggtraymanager.{c,h}: Copyright (C) 2002 Anders Carlsson
> misc.c
> Copyright (c) 2003 Leandro Pereira
>
> gtkbar.c
> Copyright (C) 1995-1997 Peter Mattis, Spencer Kimball and Josh MacDonald
>
Yep, you are right, these are indeed missing. I will now carefully
check each file, add missing copyrights and upload again.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: trayer_1.1_i386.changes REJECTED
2009/9/4 Gunnar Wolf : > Wouter Verhelst dijo [Thu, Sep 03, 2009 at 12:47:44PM +0200]: >> > > * Upstream has abandoned the program, so the package is now Debian >> > > native. >> > >> > Switching upstreams does not make a package native. >> >> How so? There is no reason why a package where the upstream and the >> Debian Developer are one and the same person could not be native. >> >> I know it is fancy and modern to think that Debian native packages >> should only be used for things that are specific to the Debian >> infrastructure, but there is nothing in policy that requires that, and >> indeed several packages (including, e.g., offlineimap) are distributed >> as such. > > Why should it be Debian-native? Do you want other distributions > carrying it to necessarily include your debian/*? Do you want to > throw stones in the way of Debian derivatives by being unable to do > packaging-specific changes while keeping track of your upstream > releases? FWIW, I wrote this answer (but did not send it): There is no point pretending there is an upstream when there clearly isn't. Pretending there is an upstream just forces me put every change into patches, thus forcing me to use a patch system (which the package did not use), and since I use hg.debian.org together with hg-buildpackage, it forces me to have two repositories, one for (the non-existent) upstream and one for for debian package. I know this is my problem, but then I guess it is my choice how I deal with that problem. If there at some point are other people/distributions interested in using the code, then they/I can just revive the upstream packaging. Sorry, but I am that kind of an Agile person... But I figured that fighting about it was even more work than going with the path system. So, I have now uploaded a non-native package. Side-note: I am hacking away on a new version of hg-buildpackage but have not yet been in touch with John Goerzen about this because it is not implemented in Haskell. :-) Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITP: mercurial-buildpackage (for those who care about Mercurial)
Executive summary: If you use Mercurial and pbuilder for package maintenance you should try out mercurial-buildpackage in http://people.debian.org/~jps/squeeze/ . I have spent some time on making an improved version of hg-buildpackage, which turned out to become a complete rewrite now called mercurial-buildpackage. The highlights are * Support dpkg source format 3.0. * Several .dsc can be imported to retain the full history when converting an existing package. * Building via pbuilder is a breeze. * Easily parsable output; same format as Lintian or Piuparts. * Complains if the repository has uncommited changes (unless --force). * Only one repository. Branches are used to keep upstream separate. I will now work on getting backporting, downstreaming (Ubuntu etc.) to be a breeze (breezy?) too. Cheers, -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
2009/11/19 Goswin von Brederlow :
> Jens Peter Secher writes:
[...]
>> * Support dpkg source format 3.0.
>
> Integration of the hg stacked patches extenstion (don't remember the
> name, the one giving you qpull/qpush) with 3.0 (quilt) format?
As I see it, there is no need for using Mercurial Queues (mq) with
mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has
the same purpose as mq, namely to wrap around quilt to achieve
automatic patch handling.
To clarify, assume you have downloaded the sample1 package from
http://people.debian.org/~hertzog/packages/debsrc3.0 which is in
format "3.0 (quilt)". To put it under Mercurial control, do
$ mercurial-initrepo sample1
$ cd sample1
$ mercurial-importdsc ../sample1_1.0-1.dsc
$ vi debian/changelog
(Add a new entry 1.0-2.)
(Then hack away on a nice new feature touching a lot of files.)
$ mercurial-buildpackage
Now dpkg-source will have created a patch file
debian/patches/debian-changes-1.0-2 containing all your hacks.
When you are satisfied, you can do
$ quilt rename nice-new-feature.diff
to give the patch a better name.
You can then start on another feature, which will again end up as
debian/patches/debian-changes-1.0-2 until you give it a better name.
Or did you have something else in mind?
>> * Only one repository. Branches are used to keep upstream separate.
>
> Support for pristine-tar?
Sure, just put place your pristine tarballs in ../ and you are fine. :-)
There is no support for keeping the pristine tarballs in the Mercurial
repository, and I do not really see any point in doing so: The
pristine tarball can be retrieved from upstream and/or the Debian
pool. But I might have missed some use cases...
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ITP: mercurial-buildpackage (for those who care about Mercurial)
2009/11/21 Goswin von Brederlow : > Jens Peter Secher writes: >> As I see it, there is no need for using Mercurial Queues (mq) with >> mercurial-buildpackage because dpkg-source format "3.0 (quilt)" has >> the same purpose as mq, namely to wrap around quilt to achieve >> automatic patch handling. > > Not quite. The Mecurial Queues are under version control. That means > I can check out last months patch series, bisect changes, see who > changed what when and so on. Hmm, the debian/patches/ are also under version control. I am afraid I still do not see a real difference... > All in a way mercurial users are use to. ...except for the above (assuming Mercurial really are used to MQ). > > That means people have to use quilt and mercurial. With mercurisl > queues you would have only mercurial and the quilt part is hidden. > > I'm not saying mercurial queues should be forced onto the user but I > think it would be nice to support them. Sure, but I do not know how to do that at the moment. :-) > > pristine-tar does not put the tarball into the repository. It only > stores the delta between taring up the upstream branch and the actual > upstream orig.tar.gz. That way you can clone a repository and build > without first having to go hunting around for the orig.tar.gz. > > Please look at it and look how git-buildpackage uses pristine-tar. Heh, I started implementing support for pristine tarballs yesterday, but now I realise that pristine-tar is a package. Well, that makes things a lot easier. I will incorporate it. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
mercurial-buildpackage, now with pristine-tar support
Executive summary: mercurial-buildpackage can now recreate pristine
upstream tarballs.
mercurial-buildpackage is a set of tools for maintining Debian
packages in a Mercurial repository, and in version 0.2 you can run
"mercurial-pristinetar 1.2.3" to recreate a tarball that is identical
to the one that was imported by mercurial-importdsc or
mercurial-importorig.
The recreation is achieved by an elaborate use of Mercurial branches
where each upstream component is given its own branch in addition to a
"pristine" branch where xdeltas and pristine-gz/pristine-bz2
information is stored; all out of sight for normal use.
Upgrading: If you have repositories created with version 0.1, then you
_should_ be able to use version 0.2 without problems, but you will
then not be able to recreate already imported upstream tarballs, only
future imports. Also notice that it is no more needed to do special
initialisation of a Mercurial repository; simply do a "hg init mypack"
to start a package.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mercurial-buildpackage, now with pristine-tar support
2009/12/3 Dmitrijs Ledkovs :
> Does it support 3.0 (quilt)
Yes.
> and puts them into mercurial queues?
No support for Mercurial Queues at the moment; see discussion a couple
of weeks ago [1].
Instead it uses dpkg-source, that is, the dpkg-source built-in patch
handler or Quilt if it is installed.
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
[1]
http://groups.google.com/group/linux.debian.devel/browse_thread/thread/4440fb8b28e9a3bb/d93dc30ec22421c9
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
QA pages and epochs: problem?
Recently, it seems that the QA pages started ignoring the epoch in changelog versions. Specifically http://packages.qa.debian.org/h/haxe.html shows an ancient version 20060912-2 as the version in sid, while it shows 1:2.4-3 as the version in testing. Have anybody else seen the like? -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Ideas for object-based git-like storage on Linux
On 2011-02-07 00:40, Roger Leigh wrote: > http://www.codelibre.net/~rleigh/hashlink.pdf Interesting! It seems that it would also be beneficial to log-structured file systems [1]. I spotted a couple of typos: Page 4: "Files may be therefore be replaced" => "Files may therefore be replaced" Page 8: "that is to say it it written once" => "that is to say it is written once" "storage is be used" => "storage is used" Cheers, -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/4d5077fa.6090...@debian.org
Re: Ideas for object-based git-like storage on Linux
On 2011-2-8 0:51 , Roger Leigh wrote: On Mon, Feb 07, 2011 at 11:53:46PM +0100, Jens Peter Secher wrote: Interesting! It seems that it would also be beneficial to log-structured file systems [1]. [1] http://en.wikipedia.org/wiki/Log-structured_file_system Cheers, /JP -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/4d516c49.1030...@debian.org
libcrypto++8/9 transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Executive summary: libcrypto++8 will be replaced by libcrypto++9. Please try to rebuild against libcrypto++-dev version 5.6.1-1 from Experimental. The plan is to prepare version 5.6.1-2 for upload to Unstable around March 2011. If this would mess up things for you or you do not have time to test out things before March, please shout out. Cheers, - -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk1Rt/kACgkQiFVdEFPVQL+NEAP5AVg48Y0YQhZWXmk4ocO6RLAg NzPEq7pdHNd+tvSWaeNHniZ8IxvO1vVDZLKKMSIJf9673dzf2tkvUks+QvT4/Ntc PgVEDgDZgHL8irnlD/qlw1yXtDlUquaTHqeUbIuCkyf7CWIMTrTcBnnNAWLHn0Jb CMWpyUeXcu6IJ+qaatw= =L5+e -END PGP SIGNATURE- -- 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/4d51b809.2010...@debian.org
Re: About new source formats for packages without patches
On 30 March 2010 16:46, Sven Mueller wrote:
> My main reason for not yet switching is that hg-buildpackage and
> svn-buildpackage don't completely support the 3.0 format yet as far as I
> can tell.
You can try out mercurial-buildpackage, where I have tried to support
"3.0 (quilt)" as good as I could: the default branch contains the
fully patched source code as well as the explicit debian/patches.
That way you can just hack away anywhere in your package and
repeatedly run mercurial-buildpackage until you are satisfied, and
then finally rename the dpkg-source autogenerated patch to something
meaningful. But I would like to hear suggestions for improvements...
Ohh, and thanks to Raphael Hertzog for doing all the hard work on the
new formats!
Cheers,
--
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
--
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/x2wc4f47b5b1003311704w73e6efafha33f5ecfd4d88...@mail.gmail.com
Bug#628920: O: asunder -- GTK Audio CD ripper and encoder
Package: wnpp Severity: normal Asunder is in good shape, upstream is responsive (and would like to not have his email made public). -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87k4d4jt5y.fsf@turing.RAVNEHOLM26
Bug#628923: O: budy -- Binary Decision Diagram library
Package: wnpp Severity: normal Package in good shape, very low activity. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87hb88jryr.fsf@turing.RAVNEHOLM26
Bug#628924: O: changetrack -- automatic log book, recording what files were changed
Package: wnpp Severity: normal Package in good shape, very low maintenance. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87ei3cjrus.fsf@turing.RAVNEHOLM26
Bug#628935: O: libcrypto++ -- C++ class library of cryptographic schemes
Package: wnpp Severity: normal Package in good shape, upstream responsive and has a Debian guest account for debugging failures. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87boygjrp7.fsf@turing.RAVNEHOLM26
Bug#628936: O: libfile-ncopy-perl -- Perl library for extended file copy functionality
Package: wnpp Severity: normal Package has not been touched for years, very low activity upstream. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/878vtkjrge.fsf@turing.RAVNEHOLM26
Bug#628937: O: libpam-ssh -- Use SSH keys to login and enable eg. single sign-on
Package: wnpp Severity: normal pam-ssh has unclear upstream development, has a lot of Debian changes, and in general need a firm hand. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/8762oojr86.fsf@turing.RAVNEHOLM26
Bug#628938: O: lua-mode -- Emacs mode for Lua programming
Package: wnpp Severity: normal Package in good shape, unclear upstream development. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/8739jsjr5k.fsf@turing.RAVNEHOLM26
Bug#628939: O: neko -- Virtual machine (byte code), interpreter and compiler
Package: wnpp Severity: normal Package in good shape, upstream responsive, low activity. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87zkm0ichg.fsf@turing.RAVNEHOLM26
Bug#628941: O: siggen -- Signal generation tools
Package: wnpp Severity: normal Package in good shape, very low activity upstream. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87wrh4icek.fsf@turing.RAVNEHOLM26
Bug#628942: O: sml-mode -- Emacs mode for Standard-ML programming
Package: wnpp Severity: normal Package in good shape, very low upstream activity. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87tyc8iccc.fsf@turing.RAVNEHOLM26
Bug#628943: O: trayer -- lightweight GTK-based systray
Package: wnpp Severity: normal Package in good shape, responsive (new) upstream. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87r57cic9g.fsf@turing.RAVNEHOLM26
Bug#628948: O: haxe -- Compiler for the Web-oriented haXe programming language
Package: wnpp Severity: normal Package in good shape, reposive upstream, although getting stable upstream sources is little tricky. The package has pseudo build failures on kFreeBSD because of the way disks are mounted on the buildds. I would suggest to simply exclude kFreeBSD to avoid this hassle because the porters apparently cannot fix it. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87oc2gibrx.fsf@turing.RAVNEHOLM26
Bug#628953: O: mercurial-buildpackage -- Utillities for maintaining a deb package in Hg repository
Package: wnpp Severity: normal Native package written by yours truly. Pristine-tar part does not work anymore, reason unknown. Everything is written in haXe, which entails some problems wrt. Process control & input/output, and I have created a branch (combined-process-input-output) in which I have started taking care of these problems, but you will need a good deal of dedication. I will help if needed. -- Jens Peter Secher, GPG fingerprint 0EE5978AFE63E8A1. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- 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/87ipsoiarc.fsf@turing.RAVNEHOLM26
Re: Bug#628953: O: mercurial-buildpackage -- Utillities for maintaining a deb package in Hg repository
On 2011-06-03 10:39, Andrew O. Shadoura wrote: > Jens, I always wanted to ask, why doesn't it sign the .dsc/.changes > files? It does not sign the result because I believe that signing a package should only happen after it has been tested, as a conscious decision. YMMV :-) Cheers, /JP signature.asc Description: OpenPGP digital signature
