Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

> Yeah, sorry, there should be --export.
>

Great!

gpg --no-default-keyring --export --keyring /etc/apt/trusted.gpg >
/etc/apt/trusted.gpg.new

fixed the problem. I now need to decide whether I should nuke and pave.

The only question that remains is: how did this happen? There must be an
issue lurking there somewhere.

Thanks for the assistance.

Pete

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

> That's your problem. Run

>
>   gpg --no-default-keyring --keyring /etc/apt/trusted.gpg >
> /etc/apt/trusted.gpg.new
>   mv /etc/apt/trusted.gpg.new /etc/apt/trusted.gpg
>
> To convert the keybox file back to a key ring.
>
>
The gpg command hangs. If I issue it without the pipe I get:

gpg: Go ahead and type your message ...

trusted.gpg appears to be empty, apart from producing the above output.
It's 32 bytes long.

I've poked around the gpg command, but I'm not actually sure what this is
supposed to achieve. Should there be a "command" as a gpg argument?

Thanks, Pete

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

>   ... In the gmail web UI,
> you click on the three dots and then move your cursor to the position
> where you want to start writing (I actually forgot to add this to the
> previous email...).
>

OK. I'm not a fan of a UI where the same element does very different
things. In the past there was a separate option for reply inline.

>
>
> These look correct. Just to clarify: Running file shows you "GPG key
> public ring" for each file?


yes


> What about /etc/apt/trusted.gpg
>
trusted.gpg: GPG keybox database version 1, created-at Fri Apr 28 07:45:49
2017, last-maintained Fri Apr 28 07:45:49 2017

>
> What you can do is manually run apt-key verify for an InRelease file, e.g.:
>
> /usr/bin/apt-key verify
> /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_InRelease
>

No can do. Closest is:

root@pete:/var/lib/apt/lists# /usr/bin/apt-key verify
/var/lib/apt/lists/debian.mirror.digitalpacific.com.au_debian_dists_stretch_Release
gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
gpgv:using RSA key 8B48AD6246925553
gpgv: Can't check signature: No public key
gpgv: Signature made Tue 23 May 2017 06:42:01 AEST
gpgv:using RSA key 7638D0442B90D010
gpgv: Can't check signature: No public key
root@pete:/var/lib/apt/lists#



> /usr/bin/apt-key verify
> /var/lib/apt/lists/dl.google.com_linux_chrome_deb_dists_
> stable_Release{.gpg,}
>
> (showing the two different invocations). If you don't have InRelease
> (or Release.gpg and Release) files, you could download one manually.
> This should error messages from gpgv.
>

Now, I don't understand the intention. Here is a listing from that
directory:

debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_contrib_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_binary-amd64_Packages.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_main_i18n_Translation-en.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_binary-amd64_Packages
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_binary-amd64_Packages.diff_Index
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_dep11_Components-amd64.yml.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_dep11_icons-64x64.tar.gz
debian.mirror.digitalpacific.com.au_debian_dists_stretch_non-free_i18n_Translation-en
debian.mirror.digitalpacific.com.au_debian_dists_stretch_Release
debian.mirror.digitalpacific.com.au_debian_dists_stretch-updates_Release
lock
partial
security.debian.org_dists_stretch_updates_main_binary-amd64_Packages
security.debian.org_dists_stretch_updates_main_i18n_Translation-en
security.debian.org_dists_stretch_updates_Release

So, I don't understand what to compare, or what to download, or where from.

Thanks, Pete

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Hi,


If you'd like to show me how I can use the gmail web interface to respond
inline and select what to quote, do go ahead. I really don't like to be
called names, especially when there is no basis for it.

Sorry, but I did miss the  stuff from David. But, all files in that
directory are -rw-r--r-- 1 root root and all files are GPG key files.

And:

stat /tmp
  File: /tmp
  Size: 4096Blocks: 8  IO Block: 4096   directory
Device: 10302h/66306d   Inode: 5373953 Links: 14
Access: (1777/drwxrwxrwt)  Uid: (0/root)   Gid: (0/root)
Access: 2017-05-24 20:21:01.468603835 +1000
Modify: 2017-05-29 17:45:53.533125958 +1000
Change: 2017-05-29 17:45:53.533125958 +1000
 Birth: -

So, it doesn't look like the issue?


Thanks, Pete

On 26 May 2017 at 19:51, Julian Andres Klode <j...@debian.org> wrote:

> On Fri, May 26, 2017 at 06:21:23PM +1000, Peter Miller wrote:
> > Julian,
> >
> > Sorry, but gmail does not allow me to reply inline, or to select what I
> > quote. I am using the only option I have.
>
> Yeah, right. No. That's a lie.
>
> >
> > I am not and did not ignore Frank's advice, which included a *count* of
> the
> > files in /etc/apt/trusted.gpg.d. That advice was followed and was a dead
> > end. Frank's advice was that the keys seem to be correct. There is a bug
> > somewhere in here, I just don't know where. I did not try to fix anything
> > from a clean install before this issue showed up.
>
> There is no Frank here, and nobody here gave you an advice to count
> files.
>
> >
> > I do appreciate you responding to me, but it's really not helping that we
> > seem to be talking at cross purposes. I am not a Debian dev, but do have
> a
> > technical background. So, I have tried my best to listen to advice, and
> to
> > do what research I can.  I am happy to follow any clear instruction, and
> > would really like not to have to reinstall the operating system to fix
> what
> > appears to be a simple problem. I understand I am using Testing, but
> there
> > must be a way out of here.
>
> David gave you very clear instructions (and I quoted them twice for you)
>
> 1. run ls -lh on all files in trusted.gpg.d to figure out permissions
> 2. run file on all files to check that they are all valid GPG public
>key files
> 3. And run a stat on /tmp to check if your system is not messed up there.
>
> You have followed *none* of the instructions, so I get the feeling
> you are just here to troll. So this is your last chance, after that
> I'll ignore you and ask for you to be banned or something.
>
> And one last time, the original quote from David:
>
> > > > > > On 23 May 2017 at 21:35, David Kalnischkies <
> da...@kalnischkies.de>
> > > > > wrote:
> > > > > > > Julian was asking basically for running both:
> > > > > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > > > > file /etc/apt/trusted.gpg{,.d/*}
> > > > > > >
> > > > > > > As he thinks it might be a permission/wrong-file-in-there
> problem,
> > > > > which
> > > > > > > is the most likely cause… I would add a "stat /tmp" as I have
> seen
> > > it
> > > > > > > a few times by now that people had very strange permissions on
> /tmp
> > > > > > > – all of which usually caused by "fixing" some problem earlier…
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

Sorry, but gmail does not allow me to reply inline, or to select what I
quote. I am using the only option I have.

I am not and did not ignore Frank's advice, which included a *count* of the
files in /etc/apt/trusted.gpg.d. That advice was followed and was a dead
end. Frank's advice was that the keys seem to be correct. There is a bug
somewhere in here, I just don't know where. I did not try to fix anything
from a clean install before this issue showed up.

I do appreciate you responding to me, but it's really not helping that we
seem to be talking at cross purposes. I am not a Debian dev, but do have a
technical background. So, I have tried my best to listen to advice, and to
do what research I can.  I am happy to follow any clear instruction, and
would really like not to have to reinstall the operating system to fix what
appears to be a simple problem. I understand I am using Testing, but there
must be a way out of here.

Regards, Pete Miller

On 25 May 2017 at 21:33, Julian Andres Klode <j...@debian.org> wrote:

> On Thu, May 25, 2017 at 08:23:34PM +1000, Peter Miller wrote:
> > Julian,
> >
> > There is no such thing as perfect security. I was and am using a trusted
> > mirror, so I'm much more worried about the Windows machines I have to use
> > at work, and are necessarily linked to my linux boxes. So, please,
> > understand that I understand the (small) risk I have taken. I wouldn't
> even
> > take the time to verify my packages later, as it's not worth the
> > investment. I have good backups of all my important stuff, and I would
> > notice a bot eventually. So, could we please get back to my question?
> >
> > Is there any way to fix my keys?
>
> This is getting ridiculous. David told you precisely what to do and I
> quoted it for you in the previous email again, if you keep ignoring that,
> that's your problem. This is likely the last time I'll quote that for you:
>
> > On 25 May 2017 at 19:00, Julian Andres Klode <j...@debian.org> wrote:
> > > You know, that bit:
> > >
> > > > On 23 May 2017 at 21:35, David Kalnischkies <da...@kalnischkies.de>
> > > wrote:
> > > > > Julian was asking basically for running both:
> > > > > ls -l /etc/apt/trusted.gpg{,.d}
> > > > > file /etc/apt/trusted.gpg{,.d/*}
> > > > >
> > > > > As he thinks it might be a permission/wrong-file-in-there problem,
> > > which
> > > > > is the most likely cause… I would add a "stat /tmp" as I have seen
> it
> > > > > a few times by now that people had very strange permissions on /tmp
> > > > > – all of which usually caused by "fixing" some problem earlier…
>
> Also please reply properly, as explained below.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

There is no such thing as perfect security. I was and am using a trusted
mirror, so I'm much more worried about the Windows machines I have to use
at work, and are necessarily linked to my linux boxes. So, please,
understand that I understand the (small) risk I have taken. I wouldn't even
take the time to verify my packages later, as it's not worth the
investment. I have good backups of all my important stuff, and I would
notice a bot eventually. So, could we please get back to my question?

Is there any way to fix my keys?

BTW, I have worked on systems that deal with legal property ownership, so I
appreciate matching effort to risk.

Thanks, Pete

On 25 May 2017 at 19:00, Julian Andres Klode <j...@debian.org> wrote:

> On Thu, May 25, 2017 at 06:49:31PM +1000, Peter Miller wrote:
> > David,
> >
> > Thanks for your time on this. I am surprised that the answer to this
> issue
> > is a re-install: it's only the keys that are corrupt somehow, and I am
> > surprised there is not a simple way to fix this. I have an unusual setup
> > with a mirrored ZFS pool as my home directory, so I'm a little
> > apprehensive. I know a re-install is usually not a big issue, but I'd
> > rather not take that risk in this situation.
>
> You are completely missing the point (any package you installed unchecked
> could be MITMed was what he said), and the second half of David's email
> (to look at the files in trusted.gpg.d and fix/remove the wrong ones).
>
> You know, that bit:
>
> > On 23 May 2017 at 21:35, David Kalnischkies <da...@kalnischkies.de>
> wrote:
> > > Julian was asking basically for running both:
> > > ls -l /etc/apt/trusted.gpg{,.d}
> > > file /etc/apt/trusted.gpg{,.d/*}
> > >
> > > As he thinks it might be a permission/wrong-file-in-there problem,
> which
> > > is the most likely cause… I would add a "stat /tmp" as I have seen it
> > > a few times by now that people had very strange permissions on /tmp
> > > – all of which usually caused by "fixing" some problem earlier…
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

David,

Thanks for your time on this. I am surprised that the answer to this issue
is a re-install: it's only the keys that are corrupt somehow, and I am
surprised there is not a simple way to fix this. I have an unusual setup
with a mirrored ZFS pool as my home directory, so I'm a little
apprehensive. I know a re-install is usually not a big issue, but I'd
rather not take that risk in this situation.

Is there no way to reset the keys?

By the way, I got into this situation without doing anything unusual, just
installing from the CD image and updating.

Regards, Pete

On 23 May 2017 at 21:35, David Kalnischkies  wrote:

> On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> > Subsequently, I have run "apt update --allow-insecure-repositories",
> which
> > worked, but a subsequent "apt-get update --allow-unauthenticated" and
> similar
> > failed to update any packages due to key errors as detailed in the
> thread.
>
> Problems are only very sheldomly solved by blindly running random
> commands. Most of the time they just "solve" something by poking a hole
> somewhere else… and disabling security is the poster child for creating
> two new problems with every problem solved this way!
>
> ALL packages you have installed while using such options could be coming
> straight from NSA^WNorthkorea^Wsome evildoers using your computer now to
> collect intel on you and your neighbors, mine cryptocurrencies or upload
> childporn in your name. So the most sensible approach is in fact a clean
> reinstall and avoiding harming your system before you ask for help next
> time. You would bring a car which makes funky sounds directly to an
> engineer, wouldn't you? Instead of taking a hammer and randomly hitting
> the car denting metal and breaking glass in the hope that it might
> magically work out anyhow if only you hit hard enough…
>
>
> > Running aptitude with options allowed the outstanding packages to be
> updated,
> > but the key errors persist in apt, synaptic and aptitude, even though the
> > correct keys seem to be installed.
>
> Debian comes with all keys to deal with the archive by default and as
> Frank has walked you through on debian-user@ they seem to be there just
> fine.
>
> (Importing any Release.gpg is btw never going to work. It contains the
> signature created with a (private) key, not the (public) key itself. You
> just need the (public) key to verify the signature.)
>
> Julian was asking basically for running both:
> ls -l /etc/apt/trusted.gpg{,.d}
> file /etc/apt/trusted.gpg{,.d/*}
>
> As he thinks it might be a permission/wrong-file-in-there problem, which
> is the most likely cause… I would add a "stat /tmp" as I have seen it
> a few times by now that people had very strange permissions on /tmp
> – all of which usually caused by "fixing" some problem earlier…
>
>
> It is btw highly unlikely that aptitude allowed an update while the
> others didn't (but then you say it didn't anyhow, so who knows) as they
> are sharing all the same code and data then it comes to downloading so
> we can work on making it "perfect" once from a security standpoint
> rather than "so lala"¹ for each individual package manager.
>
> ¹ german for "okayish", but with a (stronger) hint of "would not hold
> its ground if someone would look closer".
>
>
> Best regards
>
> David Kalnischkies
>

Bug#863179: apt: GPG errors on update and other operations

[Peter Miller]

Julian,

I thought doing one update might fix the issue, since nothing else was
working, hence --allow-unauthenticated.

I did not install or update anything in /etc/apt/trusted.gpg.d, or anywhere
else similar, so how did it get corrupted? Is there a source issue? Are
there automated checks after download?

Sorry, I don't understand what "output of file(1)" (or any of your other
advice) means. Could I have it in plain English, please? How do I replace
the GPG files? The Release.gpg files on mirrors don't import as keys.

Thanks, Pete Miller

On 23 May 2017 at 16:57, Julian Andres Klode  wrote:

> On Tue, May 23, 2017 at 10:59:32AM +1000, Pete Miller wrote:
> > Package: apt
> > Version: 1.4.1
> > Severity: important
> > Tags: d-i
> >
> > Dear Maintainer,
> >
> > I installed Stretch from the CD image to new physical hardware, and then
> > updated the system. I can't remember if errors started straight away, or
> took a
> > while to manifest.
> >
> > See this thread for some background: https://lists.debian.org/debian-
> > user/2017/05/msg00311.html
> >
> > Subsequently, I have run "apt update --allow-insecure-repositories",
> which
> > worked, but a subsequent "apt-get update --allow-unauthenticated" and
> similar
> > failed to update any packages due to key errors as detailed in the
> thread.
>
> --allow-unathenticated is for install/upgrade, I think, not for update.
> Anyway,
> your system is broken, fix it, instead of doing dangerous stuff like this:
> One
> of your files in /etc/apt/trusted.gpg.d/ is probably in a wrong format.
>
> That's what you want for .gpg files (output of file(1)):
>
> GPG key public ring, created Fri Nov 21 21:01:13 2014
>
> .asc files are valid too, containing armored public keys. Sometimes
> you get "GPG keybox database version 1" files (which gpg2 uses for
> keyrings) - these are not valid files.
>
> --
> Debian Developer - deb.li/jak | jak-linux.org - free software dev
>   |  Ubuntu Core Developer |
> When replying, only quote what is necessary, and write each reply
> directly below the part(s) it pertains to ('inline').  Thank you.
>

Bug#614462: Variable results, depending on running kernel version

[Peter Miller]

On Sat, 2012-03-03 at 13:17 +, Neil Williams wrote:
 First test:
 uname -a
 Linux debian 2.6.32-5-amd64 #1 SMP Fri Dec 23 20:09:57 UTC 2011 x86_64 
 GNU/Linux

what Debian is this?  I'd like to run a VM to see if there are more
errors.
 
 PATH=`pwd`/bin:$PATH /bin/sh test/00/t0076a.sh
 expected to fail
 FAILED test of rename EACCES

This is very strange.  To achieve this result, the rename(2) system call
has to have non-POSIX semantics... or the test run as root.

I will change the test to display the message, as if there was an error,
rather than actually call rename(2).

I'm also adding code to the scripts that involve EACCES or EPERM, so
that they pass by default if they are run by root.

  starting at a
 ---
  starting at /tmp/libexplain-10570/a

This has a different cause.  The chroot probably doesn't have /proc
mounted.  I will add a check for this in the test.


-- 
Peter Miller peter.miller@gmail.com



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614462: Variable results, depending on running kernel version

[Peter Miller]

On Sat, 2012-03-03 at 13:17 +, Neil Williams wrote:

 Having a test suite which is dependent on the architecture-dependent
 configuration of the running kernel is going to be permanently
 problematic in a Debian buildd infrastructure...

As I learn of these issues I fix them, to the extent that the kernel
state is discernible from userspace.  The idea of libexplain is to
explain errors, particularly obscure ones caused by kernel config, or
other details the user would have difficulty discovering.  (To the
extent that discovery is possible.)

There is support in libexplain for Linux capabilities.

There is not yet any support for the various Linus Sectuty Modules,
although I am bumping into them personally, so that itch may be
scratched soon.

The idea is to produce error messages that actually explain what went
wrong, rather then producing cryptice error messages like No medium
found.  Users aren't, and should not have to be, psychic.

 I'm beginning to think that libexplain is only particularly useful when
 compiled on the machine which is to use it

Given that you can chnage LSM at boot time, it needs to cope with LSM
regimens not present when built.  The only things stopping apparmor,
selinux, etc, form be supported is my time.

One of the fascinating things about distributing software with a test
suite is that, if it had no test suite, it would be packaged without
quibble.  But if a package has a test suite, and fails a handful out of
600 tests, folks get all alarmed and don't install it.  If the
debian/rules didn't run the test suite, you wouldn't be considering
pulling libexplain.  There is something broken in this logic.


-- 
Sent from Ubuntu



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#559959: fixed a while back

[Peter Miller]

fixed in version 0.24




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#579240: Possible problems in your Debian packages

[Peter Miller]

On Wed, 24 Apr 2010 Bastian Blank wrote:
 I just checked the change history, it looks random. How exactly do you
 manage to build this on your own but make it fail on most other
 machines?

This is a library that explains errors.

The last few release have all been to fix false negatives in the test
suite.

Some errors move around depending on architecture (32-bit vs 64-bit,
sparc vs x86 vs s390, etc) and test false negatives occur because of
this.  E.g. when testing EFAULT explanations.

Some systems have different strerror implementations (the numbers vary,
the texts vary, the existence varies, etc) although this doesn't happen
on Linux too much... except when ABI compatibility was the goal, e.g. on
sparc.  This is a source of test false negatives.

There are (at least) three inconsistent implementations of ioctl request
macros, all incompatible, and all used on Linux for different
architectures.  This also appears to be for ABI compatibility reasons.
This is also a source of test false negatives.

Some tests are difficult because the testing environment can vary
widely.  Sometimes it's a chroot, sometimes it's a VM, sometimes it's
fakeroot, sometimes it really is running as root.  All these affect the
ability of the library to probe the system looking for the proximal
cause of the error, e.g. the error in question ENOSPC.  This often
results in 2 or 4 or 8 explanations of an error, depending on what the
library finds, e.g. existence of useful information in the mount table,
or not.

 How exactly do you manage to build this on your own but make it fail
 on most other machines?

Because each Linux architecture, as seen from the perspective of this
library, is actually different.  I am not intentionally making it
fail.

-- 
Peter Miller pmil...@opensource.org.au



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532442: attached jetring changeset

[Peter Miller]

On Wed, 2009-06-10 at 08:27 +1000, Peter Miller wrote:
 On Tue, 2009-06-09 at 14:24 +0200, Christoph Berg wrote:
 
  This is not your key.

On further checking, I'm not sure what you are telling me.
That key is what gpg --armor --export D0EDB64D reports,
and D0EDB64D is most definitely my key.

I have triple checked, and the add-* file is correct as far as I can
tell.

What is it that makes you think it is not my key?

-- 
Regards
Peter Miller pmil...@opensource.org.au
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.


signature.asc
Description: This is a digitally signed message part

Bug#532442: debian-maintainers: DM application for Peter Miller

[Peter Miller]

Package: debian-maintainers
Version: 1.54ubuntu1
Severity: normal


new DM application for Peter Miller

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: i386 (i686)

Kernel: Linux 2.6.29.1 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-maintainers depends on no packages.

Versions of packages debian-maintainers recommends:
ii  gnupg 1.4.9-3ubuntu1 GNU privacy guard - a free PGP rep

debian-maintainers suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532442: attached jetring changeset

[Peter Miller]

-- 
Regards
Peter Miller pmil...@opensource.org.au
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.
Comment: Add Peter Miller pmil...@opensource.org.au as a Debian Maintainer
Date: Tue, 09 Jun 2009 20:59:55 +1000
Action: import
Recommended-By: Simon Horman ho...@verge.net.au, Matthew Palmer 
mpal...@debian.org
Agreement: 
http://www.mail-archive.com/debian-newma...@lists.debian.org/msg04546.html
Advocates: 
http://www.mail-archive.com/debian-newma...@lists.debian.org/msg04547.html, 
http://www.mail-archive.com/debian-newma...@lists.debian.org/msg04541.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1.4.9 (GNU/Linux)
  
  mQGiBD3SWokRBACheHqEtCDneh3yGwz92ujVwUEaFG62zjqtiyEUPC6CJIexTSvu
  y9ECTZ27N7ubiUh55VMc5MARDgvo6NoruPK7ceMGu9DtBLn7YNYSGXxwzjJAgRq0
  T/dEVPJm+khLQeu+1V3QaoR9G2qSESSa2esC5gaZ65SG2nzCJvfyopN0HwCglUFj
  cWbn7H3P4QrXYrWnZMbh7nUD/jUIcC11YYdK6nPNnQuqiwV8BkdbbXkSJFhRhYjq
  ymSPEzNydCngpAOtGgz1+bfhZt2K55r7EUb5o7H7fsM5EXsUbCa2avUdTf8UXfzF
  vglI95ZzXG8GwoGC+FEBQkgDjlGKH8W2IEtAYK1iN+tb+OMzE4FkwCZmyCOgklrl
  Mk+hBACelOFWZ5IPFFOTKzz+TjR8HsYzgPTMv7F6grjGGZwXGU0LTtjdKCFVha1i
  Ltsio/wQWfk4PkqnPPVz4jLXQphZb+EhPatNGyDvXe3uwAUfMTDL1DkiXolxFBML
  L9U+9TQGK3EppuynoPwgTcyiaRYF3EOLEDhM1jtLXZwPLI/z6bQnUGV0ZXIgTWls
  bGVyIDxtaWxsZXJwQGNhbmIuYXV1Zy5vcmcuYXU+iFwEExECABwCGwMECwcDAgMV
  AgMDFgIBAh4BAheABQJChxRTAAoJEBjYpOLQ7bZNyS0An25DlIAzkkdFiULvTvtG
  H3Ned1DYAJwJzEI9HIf42SK9eZqx7yNSzjEkUIhMBBMRAgAMBQJAYf8OBYMBMsJ7
  AAoJEGykGndDuNbIBdoAoInkSa9lKvLhlC427nSf/qhLQ6sKAKCTlV3APST3tQ4R
  6t92BhZrY/E8oohdBBMRAgAdBQI90lqJBQkDwmcABQsHCgMEAxUDAgMWAgECF4AA
  CgkQGNik4tDttk008ACeKIhf15wdjnembhZzo8ukaFrE9OUAnii/E4Mlp+F3MzhT
  OpEDuGiYD5ZXiGIEExECACIFAkCsH5cCGwMFCQw/xo4ECwcDAgMVAgMDFgIBAh4B
  AheAAAoJEBjYpOLQ7bZNQuQAn2QsRsEsZK1QBFDgahiMFYB0cWuSAJ9tko2RyxE6
  4Z2jOSSEnqPqDabL+IhGBBARAgAGBQJHpvnZAAoJEEexm7z+Bw4PIKYAnjr9jrEt
  nvlZNA6Sc4BH3wXXFZdYAJ9ZnhvdRP6cczK0CyFIdtyUF8t4HohGBBARAgAGBQJH
  p7iAAAoJEP91Fry/YZxk4icAoMmqgo1cmbwTG7OyqArTtsWPFJhuAJsGSIvilqR3
  QEKaLGegT9oDrRT0QohGBBARAgAGBQJHpyibAAoJEP+UfroG8oKk1vgAn3mnHaZO
  Sl9lbOt00yMln4hmdHDyAJ9PRLfICoJHx+Q0+HqDZ938qBiwuIhGBBARAgAGBQJH
  pt2YAAoJEISAc4An/PEu2c4An0jVeavvGuuE6m6QL1Cj5kTtHw9KAKDTjSgixLp5
  PFQIOwADiyLRWGaf74hGBBARAgAGBQJHpl5JAAoJEC46Vm8HIgIeaL8AoJKXWHDe
  XQAqCZtwGYA3/mqcobhgAKC/eiADTU6qXu4+w08aEDFZJswwYohGBBARAgAGBQJH
  pslxAAoJEChuHL7ZBgEkpp4An3UdiCAZAm3CxCHAs3EpTrig4vhMAJ4x8ebcgdbO
  jzCC7QCdDqjxQ5Ca64hGBBARAgAGBQJHpkqgAAoJEL7OkKrPE8QahdkAoKrqEiB9
  STSps0wym+Xvis5VZv3WAJ9wMtwCZwuANiZcHSCF4TyeG6E/9IhGBBIRAgAGBQJH
  pZz5AAoJEKvxFi6jxiGjYVAAnjBjZDtZ9+/IKLK7zeQO9w9972qGAKDzwT+OzFDx
  kJilQ2IrGcjJtMKgC4hGBBARAgAGBQJHnZUcAAoJEIQaDmBvOluEFwsAn3AnU8tG
  5yQKmM8E8xOGmYStW6QEAKCwD7xfF2TcMmG9D7+D85m+D5P20IhGBBARAgAGBQJH
  ncLpAAoJEJmxCA6m667ySbEAn3JuZ+FAv8M+E5n3aDTAcf8P4Z1PAKDIKQv86/GX
  w7FX0pGysw5/gL1B+ohGBBARAgAGBQJHnxVoAAoJEH4AJ5d2q8HPrHoAnizpeF00
  wtVz3pz2qVDrdphvx0w1AJ4gOpz5zdYw7ujJ0gc412BCA70dGohGBBARAgAGBQJH
  pV7CAAoJEHAIPP5rgcaHuokAoONfVCGi3AbQqdbtVztW20LSgE6QAJ9VmbljrwA4
  0WKcgCqhhz5r4QuhSIhGBBARAgAGBQJHow0MAAoJEP10Og25j46JaaQAni0RDXO0
  rxMU4Ew/PMLw23cUYl3XAJ9Py2Kb8vgTENB3Kn5WL1s7QRWb/ohGBBARAgAGBQJH
  ooL3AAoJEAGvk9mRz6NN+aIAniU59tt04lsu7HZ3hzznbxbAWSwyAJ9JKnBqyETZ
  0AhgF/2NIdw4a6vME4hGBBMRAgAGBQJHnk+1AAoJENKGzgwMYreRW1AAoIU6NVk/
  B+UgeQqqg+8JUZwCqoShAKCPoNU13FEy7Mml7NtOkaVBIuw/sIhGBBARAgAGBQJH
  qVWiAAoJEI5i5/dkARqLTBAAoJJWbSBLqY5gO8urLVAf968PAM52AJ9+7zoS3l+q
  dc4ZRKxfBBWdMn2sDIhGBBARAgAGBQJHqm2wAAoJEE+dye8NwyeR/YwAnjQrSxdI
  grnUdKfzEr2UG3D2o5ExAJ0ULfSnvGvY/Vfs88Q1UnN/AGOa4YhGBBARAgAGBQJH
  rEmbAAoJECoukZTv5sNMVTYAoKpKkRgNK61sB1UVnvL819G4zdbyAKCxcZ4ev6fp
  3H7WQPEctxbTD9oCnYhGBBARAgAGBQJHsHvRAAoJEBa6SxZw9CfDBMMAn2tLqtZX
  fvy4U/de7ZYIlqkxrjBuAJ9oYXFwrFniZDbVuzHJE5Mp1dWFDohGBBARAgAGBQJH
  tROeAAoJEG7oBecoJwnJ9LgAn07qNDS4OH+5W6SqPcWbolIRyf4TAJ9YaPAH6M+7
  3sAFjOdHo+c2A3lBv4hGBBARAgAGBQJIXXAbAAoJEMKwefz1x1JWeEAAn1IZaFg9
  zF70OHS17VLoMaoTN0CHAKCoubWt7mwoCvQrXg/P3yYSe5cCz4hGBBARAgAGBQJI
  XuihAAoJEP91Fry/YZxkC/EAoNxSgBgvDbNItE4xGuI+GzyVIXWQAJ9HU3e8DC0r
  JUHGnSn1Edt6iJfVNIhGBBARAgAGBQJI+oYYAAoJELB55zsZzsfVnZ8AniexFsLZ
  11gxABBqWjiI+1cjjzClAKCkc5+9z7R11mhMCYubeI1qWMmF44hGBBARAgAGBQJJ
  tyNqAAoJEAPAAj4FQQ6X6ewAoJNLTZMnvdbVVI1wU9cZSDKTG6cRAKDULhvNDTDs
  P/oADEDknvmeQpm+gbQoUGV0ZXIgTWlsbGVyIDxwbWlsbGVyQG9wZW5zb3VyY2Uu
  b3JnLmF1PohgBBMRAgAgBQJJQFwtAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AA
  CgkQGNik4tDttk3pkACfduhdSNQwjnDfLqPurJ8QWhZ8NOQAnjdClINalLhFq4/W
  ls9L4zSTxJNIiEYEEBECAAYFAkm3I2oACgkQA8ACPgVBDpf+uQCg2suGLlBXkBhu
  KtKp85s7D9DED6UAnRm7PcaiQO7q71//JzAuEwLLCJ/4uQENBD3SWosQBADePvxt
  cpmbZoJ9Pme06n2xpK64fLflNwwrrkhSCUfCX662bzg4Q0MsfyZIPxgJQLzNPEsv
  hYvqhnwJyZ55+1MLXldfwNdZTwKNaZJQThFQUYx/x8ILm5LDu7pLZhmBozqiGBaV
  z1EU1VzNAuWxYfcYhZ3uT6eSmbhFTh0RiZhRfwADBQQA2MLfmfx262uhY67jNA5B
  nX+9MMopNd22zWG1p3T8h27IwCIHWP+gKMBLw5PEczqroPe3eKEClfps5X4gXpLa

Bug#532442: attached jetring changeset

[Peter Miller]

On Tue, 2009-06-09 at 14:24 +0200, Christoph Berg wrote:

 This is not your key.

I followed the instructions in

http://wiki.debian.org/Maintainers#BecomingaDebianMaintainer

thus, it is the output of

cp /usr/share/keyrings/debian-maintainers.gpg .
gpg --export ID of your key | gpg --import --no-default-keyring 
--keyring $PWD/debian-maintainers.gpg
jetring-gen /usr/share/keyrings/debian-maintainers.gpg 
debian-maintainers.gpg 'Add your name and e‐mail address as a Debian 
Maintainer'

I have no idea what it contains, just doing what was asked.

I have attached the output of

gpg --armor --export D0EDB64D  D0EDB64D.pub

That is definitely my public key.

-- 
Regards
Peter Miller pmil...@opensource.org.au
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.


D0EDB64D.pub
Description: application/pgp-keys


signature.asc
Description: This is a digitally signed message part

Bug#532267: ITP: fstrcmp -- library of fuzzy string comparison functions

[Peter Miller]

Package: wnpp
Severity: wishlist

Package: fstrcmp
License: GPLv3+
Homepage: http://fstrcmp.sourceforge.net/
Description:
The fstrcmp library provides an fstrcmp function that returns a
number between 0.0 (nothing alike) and 1.0 (identical); this can
be used to suggest likely alternatives in error messages. Fuzzy
comparisons for byte arrays, wide character strings, and
multi-byte character strings are also available. In addition,
there are integer alternatives for systems with slow floating
point emulation.



-- 
Regards
Peter Miller pmil...@opensource.org.au
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#507855: ITP: libexplain -- explain errno values returned by libc functions

[Peter Miller]

Package: libexplain
Severity: wishlist

The libexplain package provides a library which may be used to explain
Unix and Linux system call errors.  This will make your application's
error messages much more informative to your users.

Homepage: http://libexplain.sourceforge.net/
Copyright: Peter Miller [EMAIL PROTECTED]
License: LGPL

Packages built on Ubuntu Intrepid: http://libexplain.sourceforge.net/


Regards
Peter Miller [EMAIL PROTECTED]
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

If the programmer can simulate a construct faster than a compiler can
implement the construct itself, then the compiler writer has blown it
badly. -- Guy Steele


signature.asc
Description: This is a digitally signed message part

Bug#356636: FTBFS with G++ 4.1: extra qualification

[Peter Miller]

On Mon, 2006-03-13 at 01:57 +, Martin Michlmayr wrote:
 Your package makes other packages fail to build with G++ 4.1.

Could you please expand on what makes other packages fail to build
means?  There are at least 4 things you could mean:

Do you mean that building aegis itself fails and does not complete?
The accompanying patch would seem to indicate this is the case.

Do you mean that by compiling aegis-4.21, without install, other
packages fail to build after that?  Presumably because the ./configure;
make somehow escapes its work area.  If so, what files are involved
outside the build area?

Do you mean that by compiling and installing aegis-4.21, other packages
fail to build after that?  If so, what install files are involved? 

Do you mean that compiling installing and running aegis-4.21 that other
packages subsequently fail to build?  Is it packages being built via
aegis, or packages being build outside Aegis' control?  Either way, what
files are involved?

 A patch is below.

Thanks.  It will be in the 4.22 release.

-- 
Regards
Peter Miller [EMAIL PROTECTED]
/\/\*http://www.canb.auug.org.au/~millerp/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.


signature.asc
Description: This is a digitally signed message part