Bug#1014628: FWD: Re: git-annex arm 32-bit builds

[Joey Hess]

I was looking at this bug the other day trying to determine why
git-annex was not in testing, and did not realize it was due to this
dbus issue. My mail below digs into it, if the issue is still
happening.

- Forwarded message from Joey Hess  -

Date: Mon, 23 May 2022 12:48:21 -0400
From: Joey Hess 
To: Sean Whitton 
Subject: Re: git-annex arm 32-bit builds

Sean Whitton wrote:
> git-annex is failing on Debian's autobuilders for armel and armhf.  It
> looks like an actual type error rather than the linker failing or
> something like that \o/
> 
> Would you be able to take a look, please?
> 
> https://buildd.debian.org/status/fetch.php?pkg=git-annex&arch=armel&ver=10.20220504-1&stamp=1652058911&raw=0

What fun.. addMatch comes from libghc-dbus-dev, and has type

addMatch ::
  Client
  -> MatchRule
  -> (DBus.Internal.Message.Signal -> IO ())
  -> IO SignalHandler
-- Defined in ‘DBus.Client’

I have verified in an armel (testing) chroot that it has that type. FWIW,
git-annex is building successfully for me in that chroot. That has
the identical package version 1.2.16-1+b1 that the autobuild log has.

Somehow, the autobuilder is seeing a different type for it despite the same
version of the same package being installed. The type seems to be :: ByteString.

I also looked at the source of the haskell package and it does not have any
conditional compilation or other way for addMatch to have that type, that
I can see.

This seems to point to the autobuilder having some manually hacked up version
of the haskell library installed on it that somehow overrides the package.
Or, ghc is somehow getting massively confused and is finding the wrong symbol
or something like that.

It would be interesting, I think to find out what is in that ByteString!
I suppose you could upload a package with something like this in its rules:

ghc -e 'import DBus.Client' -e 'print DBus.Client.addMatch' || true

-- 
see shy jo



- End forwarded message -
-- 
see shy jo


signature.asc
Description: PGP signature

Bug#997933: me too

[Joey Hess]

Seeing this bug after upgrade. My imap server is dovecot.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#953621: fixed in new version

[Joey Hess]

version 1.0.1 fixes this

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Joey Hess]

It could be converted to haskeline or raw IO, but gnu readline is the
kind of library I think it makes sense to have language bindings to, and
to use the bindings.

This patch seems to fix the build problem:

--- readline-1.0.3.0.orig/readline.cabal2020-06-17 17:09:11.438264895 
-0400
+++ readline-1.0.3.0/readline.cabal 2020-06-17 17:11:23.524724389 -0400
@@ -29,5 +29,5 @@
 build-depends: base < 3
   include-dirs:include
   includes:HsReadline.h
-  install-includes:HsReadline.h HsReadlineConfig.h
+  install-includes:HsReadline.h
   c-sources:   HsReadline_cbits.c

I've sent this patch to the author of the library.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#921688: saw this

[Joey Hess]

This is still happening, the legitimate public servers may not work with
electrum 3.3, but there are dozens of rogue servers that do and that are
exploiting this bug.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#924800: [PATCH] resolve race in test cleanup by making second attempt more forceful

[Joey Hess]

Sean Whitton wrote:
> Errors are like this:
> 
> .t/gpgtest/9/S.gpg-agent.extra: 
> removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:r
>  emovePathRecursive:getSymbolicLinkStatus: does not exist (No such file or 
> directory)
> 
> i.e. the problem seems to be files vanishing while
> removeDirectoryRecursive is running.  removePathForcibly ignores such
> errors.

> + removePathForcibly tmpdir

I'd certianly like to use removePathForcibly -- after all it was added
in response to a bug report I filed about this very kind of problem.

But, the first version of ghc to include it was 8.4.2, which is newer
than the 8.0 minimum I think git-annex supports now, and also newer than
what's in Debian stable. So it would need to be 
#if MIN_VERSION_directory(1,2,7)

It also seems very unlikely that something would wait around for 10
seconds while git-annex is delaying to let any processes that might be
running finish their cleanup, and then run at exactly the same time as
the removeDirectoryRecursive. Since the earlier removeDirectoryRecursive
failed on the same file, I have the feeling the problem is not actually
with the file vanishing out from under it, but something else to do with
it being a socket.. It seems to me that removePathForcibly would
probably at best ignore the error in removal and so leave a .t directory
hanging around at the end?

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#847677: "unable to decommit memory" data loss

[Joey Hess]

Package: ghc
Version: 8.0.1-14
Severity: serious

git-annex: unable to decommit memory: Invalid argument

This happened with a git-annex built with this ghc, and bundled with
Debian's glibc (essentially a chroot), on a Fedora system with a 4.4.14
Linux kernel.

It apparently then led to memory corruption, since git-annex created
some very bogus symlinks:

lrwxrwxrwx 1 user user 338 Jun 17 22:36 
bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> 
*??:?;J?

So, we seem to have data loss, presumably any git-annex binary built
with this ghc and used with a too old kernel. Could also affect other
haskell programs.

The ghc bug leading to this problem has been fixed:

https://ghc.haskell.org/trac/ghc/ticket/12865

Could you please fast-track this fix into Debian?

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ghc depends on:
ii  dpkg 1.18.14
ii  gcc  4:6.1.1-1
ii  libbsd-dev   0.8.3-1
ii  libc62.24-5
ii  libc6-dev2.24-5
ii  libffi-dev   3.2.1-6
ii  libffi6  3.2.1-6
ii  libgmp-dev   2:6.1.1+dfsg-1
ii  libgmp10 2:6.1.1+dfsg-1
ii  libncurses5-dev  6.0+20160917-1
ii  libtinfo56.0+20160917-1

ghc recommends no packages.

Versions of packages ghc suggests:
ii  ghc-doc  8.0.1-14
ii  ghc-prof 8.0.1-14
pn  haskell-doc  
pn  llvm-3.7 
ii  perl 5.24.1~rc3-3

-- no debconf information

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#840516: doesn't work with django 1.10

[Joey Hess]

I suppose this is the problem that this bug report is about:

root@ia-bak:/usr/local/propellor# graphite-manage 
Traceback (most recent call last):
  File "/usr/bin/graphite-manage", line 15, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 367, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 341, in execute
django.setup()
  File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in 
populate
app_config.import_models(all_models)
  File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/graphite/events/models.py", line 6, in 

from tagging.managers import ModelTaggedItemManager
  File "/usr/lib/python2.7/dist-packages/tagging/managers.py", line 8, in 

from tagging.models import Tag, TaggedItem
  File "/usr/lib/python2.7/dist-packages/tagging/models.py", line 10, in 

from django.contrib.contenttypes import generic
ImportError: cannot import name generic

Downgrading python-django to 1.9.8 and python-django-tagging to 0.4 did clear
this up.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#814055: has broken binding to libgnutls-deb0.so.28

[Joey Hess]

Yaroslav Halchenko wrote:
> # ldd 
> /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.10.3/network-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC/libHSnetwork-protocol-xmpp-0.4.8-AArRa3ialU19Kz62aVPiMC-ghc7.10.3.so
>  | grep gnutls-deb
> libgnutls-deb0.so.28 => not found

joey@darkstar:~>dpkg -S libgnutls-deb0.so.28
libgnutls-deb0-28:amd64: /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
libgnutls-deb0-28:amd64: /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28.41.12

But, libghc-gnutls-dev now depends on libgnutls30. Seems that 
libghc-network-protocol-xmpp-dev was not updated after that change..

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#795644: git-annex: configure eats all memory

[Joey Hess]

Joey Hess wrote:
> apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev 
> libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev 
> libghc-http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev 
> libghc-resourcet-dev libghc-monad-control-dev libghc-edit-distance-dev 
> libghc-sandi-dev libghc-json-dev libghc-utf8-string-dev libghc-hslogger-dev 
> libghc-monad-logger-dev libghc-http-conduit-dev libghc-safesemaphore-dev 
> libghc-uuid-dev libghc-quickcheck2-dev libghc-optparse-applicative-dev 
> libghc-cabal-dev git cabal-install

Also, if you remove one of these necessary dependencies, eg
libghc-optparse-applicative-dev, cabal configure -v3 will show the
problem resolver exhaustively trying to resolve the dependencies and
failing, without using much memory. 
It then goes ahead and runs Setup configure, which OOMS.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#795644: git-annex: configure eats all memory

[Joey Hess]

Joachim Breitner wrote:
> If we can isolate the problem nicely, I’ll be happy to discuss this
> with upstream.

deboostrap sid

in chroot:

mount -t proc proc /proc
apt-get -y install ghc libghc-ifelse-dev libghc-missingh-dev 
libghc-unix-compat-dev libghc-data-default-dev libghc-exceptions-dev 
libghc-http-types-dev libghc-bloomfilter-dev libghc-old-locale-dev 
libghc-resourcet-dev libghc-monad-control-dev libghc-edit-distance-dev 
libghc-sandi-dev libghc-json-dev libghc-utf8-string-dev libghc-hslogger-dev 
libghc-monad-logger-dev libghc-http-conduit-dev libghc-safesemaphore-dev 
libghc-uuid-dev libghc-quickcheck2-dev libghc-optparse-applicative-dev 
libghc-cabal-dev git cabal-install
git clone git://git-annex.branchable.com/ git-annex
cd git-annex
ghc --make Setup
cabal configure # succeeds
./Setup configure # OOM

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#795644: git-annex: configure eats all memory

[Joey Hess]

Joachim Breitner wrote:
> I think I got it: Cabal tries to infer what feature are supported by
> looking at the dependencies, and their flags, and mumble mumble complex
> search space.

Except while Cabal falls over, cabal-install does not.

For example:

joey@kite:~/git-annex>dpkg-checkbuilddeps 
dpkg-checkbuilddeps: Unmet build dependencies: libghc-dbus-dev (>= 0.10.7) 
libghc-fdo-notify-dev (>= 0.3) libghc-yesod-dev (>= 1.2.6.1) 
libghc-network-protocol-xmpp-dev (>= 0.4.3-1+b1)

joey@kite:~/git-annex>cabal configure >/dev/null || echo failed
joey@kite:~/git-annex>

(Used around 8 mb of memory)

joey@kite:~/git-annex>./Setup configure >/dev/null || echo failed
Killed
failed

(Used over 2 gb of memory)

Note that libghc-cabal-dev was installed, so that Setup should have been
built using version 1.22.1.1-2+b3.

So, why does Cabal's dependency resolver perform so much worse than
cabal-install's?

Note that git-annex 5.20150812 went back to using cabal configure,
rather than Setup configure, so I expect it will probably build
everywhere again. There seems to be a bug somewhere in the cabal system
however.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#774898: has anyone actually tested this patch?

[Joey Hess]

Holger Levsen wrote:
> has anyone actually tested this patch?

Yes.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#774376: when run with old kernel, docker exec silently uses real root filesystem as container filesystem

[Joey Hess]

Tianon Gravi wrote:
> I would actually be very surprised if the issues you've encountered so
> far are the only issues with Docker on a 3.2 kernel.

Just to be clear, my intent was not to use docker with an old kernel.
I was just deploying a system whose configuration included docker,
and since docker started up despite the old kernel version, it was used
as part of the deployment.

This could happen lots of other ways too, like the wrong kernel being
chosen in a boot menu.

I agree that docker should refuse to run if used with an old kernel.
This could be done in the Debian init script if not upstream.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#774376: when run with old kernel, docker exec silently uses real root filesystem as container filesystem

[Joey Hess]

Package: docker.io
Version: 1.3.3~dfsg1-1
Severity: serious

Here's a system that was upgraded to unstable but not yet rebooted into the new
kernel..

root@clam:~>uname -a
Linux clam 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
root@clam:~>touch /hello-host
root@clam:~>docker exec oldusenet-shellbox.clam.kitenet.net.propellor ls 
/hello-host
/hello-host

This is pretty horrible! Note that only docker exec behaves this way;
docker run and docker attach operate with the filesystem correctly chrooted
to the container.

Also, it seems that not only the filesystem, but process namespacing is broken.

root@clam:~>docker exec oldusenet-shellbox.clam.kitenet.net.propellor ps -ax 
|grep grep
20600 pts/4S+ 0:00 grep grep

I didn't check network namespacing, but my guess is docker fails
to enter any namespace because of the old kernel, and then fails to
propigate the error because Fail.

There does not seem to be anything interesting in docker.log.

I have filed this severity serious as a compromise. I think this bug could
cause data loss. Using docker exec to do part of a container's deployment,
and deploying changes to the host system could result in arbitrary horrible
effects, up to and including removing files from the host system. However,
in my case, I luckily was deploying a new system, so I can throw away
the resulting mess.

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages docker.io depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  iptables 1.4.21-2+b1
ii  libapparmor1 2.9.0-3
ii  libc62.19-13
ii  libdevmapper1.02.1   2:1.02.90-2
ii  libsqlite3-0 3.8.7.4-1
ii  perl 5.20.1-4

Versions of packages docker.io recommends:
ii  aufs-tools   1:3.2+20130722-1.1
ii  ca-certificates  20141019
ii  cgroupfs-mount   1.1
ii  git  1:2.1.4-2
ii  xz-utils 5.1.1alpha+20120614-2+b3

Versions of packages docker.io suggests:
pn  btrfs-tools  
ii  debootstrap  1.0.66
pn  lxc  
pn  rinse

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#772239: git-remote-gcrypt: bashism in /bin/sh script

[Joey Hess]

Raphael Geissert wrote:
> I've ran checkbashisms (from the 'devscripts' package) over the whole
> archive and I found that your package has a /bin/sh script that uses a
> "bashism".
> 
> checkbashisms' output:
> > possible bashism in ./usr/bin/git-remote-gcrypt line 102 (setvar 'foo'
> > 'bar' should be eval 'foo="'"$bar"'"'):
> >   setvar "$1" "$f_append_tmp_$2"

Why? 

setvar()
{
isnull "${1##@*}" || echo_die "Missing @ for return variable: $1"
eval ${1#@}=\$2
}

AFAICS, setvar is not a bash builtin at al.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#772043: option parsing 100% broken

[Joey Hess]

Package: guthub-backup
Version: 1.20141110
Severity: serious

joey@darkstar:~/src/github-backup>./github-backup joeyh
Usage: github-backup [USERNAME|ORGANIZATION] [--exclude USERNAME/REPOSITORY]

This leaves the program mostly useless, unable to backup all a user's
repos, although it can still be run in a git repo to back up just that
one single repo.

The fix is simple, and I have released a new version upstream that fixes
this bug. Here's the entire substantive patch:

-   owneropt = (argument (Just . Owner))
+   owneropt = Owner <$> (argument str)


-- 
see shy jo


signature.asc
Description: Digital signature

Bug#771334: upgrade hosed dovecot; Couldn't parse private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: ANY PRIVATE KEY

[Joey Hess]

Source: dovecot
Version: 1:2.2.13-7
Severity: serious

After upgrading to this version, I cannot connect to dovecot's imap or
pop servers.

joey@darkstar:~>telnet kitenet.net imap
Trying 66.228.36.95...
Connected to kite.kitenet.net.
Escape character is '^]'.
Connection closed by foreign host.

Offlineimap fails connecting to imaps; the ssl handshake fails.

journald has logged:

Nov 28 11:33:44 kite dovecot[14616]: imap-login: Fatal: Couldn't parse
private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line:
Expecting: ANY PRIVATE KEY
Nov 28 11:33:44 kite dovecot[14604]: master: Error: service(imap-login):
command startup failed, throttling for 4 secs
Nov 28 11:33:48 kite dovecot[14616]: imap-login: Fatal: Couldn't parse
private ssl_key: error:0906D06C:PEM routines:PEM_read_bio:no start line:
Expecting: ANY PRIVATE KEY
Nov 28 11:33:48 kite dovecot[14604]: master: Error: service(imap-login):
command startup failed, throttling for 8 secs

I suppose it's not cooincidental that the change in -7 had something to
do with cert locations. My dovecot cert appears to be in
/etc/dovecot/private/dovecot.pem, and it starts with 
-BEGIN PRIVATE KEY-

Downgrading to -6 worked around this.

-- 
see shy jo


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

Bug#768093: marked as done (possible data loss when --git-dir is set to wacky thing)

[Joey Hess]

severity 768093 important
thanks

On second thought I don't consider this RC:

* It doesn't seem to actually result in very significant data loss.
* Pointing --git-dir at something not a git repo is asking for undefined
  behavior. This is a little more undefined than could be desired,
  but the user is mucking around with internals.

With that said, if git-annex were being updated for some other reason,
it would be fine to cherry-pick 334f3669791510f30a184d1b6c8d7196d0f19e12
which removes the problimatic transition code.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#768093: possible data loss when --git-dir is set to wacky thing

[Joey Hess]

Package: git-annex
Version: 5.20141024
Severity: serious

http://git-annex.branchable.com/bugs/misuse_of_--git-dir_might_destroy_a_git_repository_completely/

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#766459: debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system

[Joey Hess]

Santiago Vila wrote:
> Instead, the work of debootstrap is precisely to guess the right order
> in which packages should be configured so that everything work.
> 
> In other words, essential packages should not get in the business of
> breaking dependency cycles, because that's debootstrap job.
> 
> This way, maintainer scripts in essential packages are kept "clean"
> and all the hacks required for bootstrap are "accumulated" (so to speak)
> in debootstrap and similar tools.

As a debootstrap maintainer, I can't say I agree with this.

There are very few hacks and special cases of ordering in debootstrap today,
and for our sanity we'd like to keep it that way. I consider such
complications to be warts that need to be gotten rid of eventually.

Just compare /usr/share/debootstrap/scripts/{sid,sarge}. Which would
you rather maintain? And BTW that "sid" script works for 5 different
releases of debian, largely because it's not full of special cases and
hacks specific to particular releases.

> You will find a more complete explanation of this in the logs for
> Bug#760568 where I'm asked no less than to depend on base-passwd,
> which is essential! IMHO, this is definitely not the way to go.

It's past time to be untangling the Essential hairball. Correct dependency
metadata is much more scalable than hacks in debootstrap.

Stop being part of the problem, and add the dependency already..

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?

[Joey Hess]

Petter Reinholdtsen wrote:
> Here is another draft, this time also providing the module name.  I
> dropped the code looking in /proc/modules, as three ways to find
> firmware seem a bit too much.

Looking at dmesg might fail if something is spamming it and the message
drops out of the ring buffer. Maybe it would be better to look in syslog?

The modinfo check, which has been removed, avoids that problem,
although it doesn't work for some modules that don't load at all when
missing firmware. I don't know how many modules have that behavior, but
if most of them don't, the modinfo check seems worth keeping as more
robust for the modules it does work for.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#747141: [debhelper-devel] Bug#747141: debhelper: "dh_installdocs --link-doc" breaks binNMUs

[Joey Hess]

Aurelien Jarno wrote:
> We have scheduled a few thousands of binNMUs on s390x due to the libc
> ABI breakage. It occurs that most of the non binNMUs safe packages are
> wrongly using this --link-doc option.
> 
> I am therefore increasing the severity of this bug. dh_installdocs
> --link-doc should refuse to do links between arch:all and arch:any
> packages.

Do you have a proposed change that doesn't make thousands of packages
have RC bugs of their own?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#763078: confirmed llvm change broke ghc

[Joey Hess]

Gianfranco Costamagna wrote:
> llvm maintainer (Sylvestre) says that llvm-3.4 is going to disappear
> (not before jessie, but somewhen after), and llvm-3.5 is built
> correctly on arm{el,hf}.
> 
> Isn't it better to just upload with llvm-3.5 and do some binNMUs
> instead of using the old one and be hit (or be a blocker) for the
> future RM llvm-3.4 bug?
> 
> I'm just wondering if there is something behind the 3.4 decision.

Debian-release wrote:
> *Remember*: On the 5th of November, the version of your package *in
> testing* must be in its desired state for Jessie.

I think we will need to do that, at an appropriate point in the release
cycle. I'd say just after the release is out, rather than now.

* Rebuilding packages on armel and armhf could take quite some time.
* Assuming the objects built with 3.4 are not compatable with those
  built with 3.5, packages might need to be rebuilt in dependency order,
  which I don't know if we have automated.
* The newly built stuff would have no testing compared with the stuff
  in the archive.
* I don't know if simply rebuilding ghc with the new llvm works.
  (I don't even know what the root cause of the failure is.)
  I know that ghc contains llvm code generation and that it has had to
  be patched in the past for compatability with different versions of
  llvm.
* There would probably be some bootstrapping step in building ghc with
  this change. I haven't thought out how it would work.
* We will want to be upgrading to a new ghc after jessie anyway, and
  it seems likely at that point any llvm-3.5 compatability issues would
  be sorted out upstream already for us.
* In any case, my modifications to ghc to make it explicitly use a
  single version of llvm are the right thing to do, and a necessary first
  step.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#763078: confirmed llvm change broke ghc

[Joey Hess]

Sylvestre Ledru wrote:
> Yes, I know :(
> However, 3.5 has been released a few weeks before this freeze, 3.4 is
> unmaintained,
> 3.5 will be maintained a bit more, Ubuntu is also doing the switch to
> 3.5 and I wanted to default Debian
> on the last version. And as you found, the workaround is easy, stick
> with 3.4.

One wonders what would have happened if 3.5 was released just after the
freeze, rather than just before it. If it would have been ok to leave
the default at 3.4 in that case, I don't see why it wouldn't be ok to
leave the default at 3.4 in this case too.

> Sorry for the inconvenience

Which may include us having to rebuild every single haskell package in
debian on armel and armhf, because god knows what is breaking how. :/

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#763078: confirmed llvm change broke ghc

[Joey Hess]

Here's some debian/rules hacks to fix this.
This forces use of llvm-3.4 for building ghc, as well as
modifying the wrapper scripts to force use of that version at runtime.

The control file also needs to be changed to depend on llvm-3.4, rather
than llvm.

Note that just uploading ghc with this patch should suffice; there's no
need for manual building on arm.

Since this bug could be resuting in bad builds of haskell libraries/binaries
on arm, I am going to try to make a ghc release as soon as I can figure out
enough darcs to do so.

ifneq (,$(findstring $(DEB_HOST_ARCH), armel armhf))
# Force use of a specific llvm package, the same version that ghc
# depends (and build-depends) on.
LLVM_PATH=/usr/lib/llvm-3.4/bin
export PATH:=$(LLVM_PATH):$(PATH)
endif

ifneq (,$(findstring $(DEB_HOST_ARCH), armel armhf))
# Ensure that the same llvm used to build ghc is used at runtime.
sed -i "s,exec ,PATH=\"$(LLVM_PATH):\$$PATH\"\nexport PATH\nexec ," 
debian/tmp/usr/lib/ghc/bin/ghc-$(ProjectVersion) 
debian/tmp/usr/lib/ghc/bin/ghc-pkg-$(ProjectVersion) 
debian/tmp/usr/lib/ghc/bin/ghci-$(ProjectVersion) 
debian/tmp/usr/lib/ghc/bin/runghc-$(ProjectVersion) 
debian/tmp/usr/lib/ghc/bin/hsc2hs 
debian/tmp/usr/lib/ghc/bin/haddock-ghc-$(ProjectVersion)
endif

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#763078: confirmed llvm change broke ghc

[Joey Hess]

Confirmed that installing llvm-3.4 and putting /usr/lib/llvm-3.4/bin
first in PATH before running ghc lets it build working executables on
armel and armhf.

This is certianly a bug in ghc. It should not depend on llvm, but on the
llvm-$ver it was built against, and it should use the toolchain from
that specific version of llvm.

This could also be be considered a bug in llvm. Changing the
dependency package to use llvm-3.5 less than a week before the slushy
freeze is perhaps not the best idea?

I think llvm should be prevented from migration to testing until this is
sorted out in ghc and/or lvm, so I am leaving this bug assigned to both
packages.

There's also the worry of what happens if the autobuilders have built
any haskell libraries using the new llvm on armel/hf. If there's been an
ABI break in the code generated by llvm, that seems like it could get
messy fast.

-- 
see shy jo, off to work around this in order to get a security fix into testing


signature.asc
Description: Digital signature

Bug#763078: ghc no longer builds working executables on armel, armhf

[Joey Hess]

Package: ghc, llvm
Version: 7.6.3-16
Severity: serious

It seems that ./Setup configure segfaults:

(sid_armhf-dchroot)joeyh@harris:/tmp/git-annex-5.20140926$ ./dist/setup/setup 
configure
Segmentation fault

https://buildd.debian.org/status/fetch.php?pkg=git-annex&arch=armel&ver=5.20140926&stamp=1411825516

This segfault is reproducible (happened on armel and armhs buildds and then I
reproduced it on harris.debian.org). git-annex built ok last week.

Even worse, main = print "hello" is miscompiled on armhf:

(sid_armhf-dchroot)joeyh@harris:/tmp$ ghc --make test
[1 of 1] Compiling Main ( test.hs, test.o )
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
Linking test ...
./test
(sid_armhf-dchroot)joeyh@harris:/tmp$ ./test
Illegal instruction

And the same simple program no longer works on armel either:

(sid_armel-dchroot)joeyh@abel:~/tmp$ ghc --make test
[1 of 1] Compiling Main ( test.hs, test.o )
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
Linking test ...
(sid_armel-dchroot)joeyh@abel:~/tmp$ ./test
test: schedule: re-entered unsafely.
   Perhaps a 'foreign import unsafe' should be 'safe'?
(sid_armel-dchroot)joeyh@abel:~/tmp$ echo $?
1

I think that this was cuased by the introduction of llvm-3.5, while
ghc etc was built using llvm-3.4.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#762761: security fix incomplete

[Joey Hess]

Package: bash
Version: 4.2+dfsg-0.1+deb7u1
Severity: grave
Tags: security

http://seclists.org/oss-sec/2014/q3/679

root@diatom:/tmp/empty>bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
root@diatom:/tmp/empty>ls
root@diatom:/tmp/empty>X='() { function a a>\' bash -c gohomeyourdrunk
bash: X: line 1: syntax error near unexpected token `a'
bash: X: line 1: `'
bash: error importing function definition for `X'
root@diatom:/tmp/empty>ls
gohomeyourdrunk
root@diatom:/tmp/empty>

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#749795: holes in secure apt

[Joey Hess]

Christoph Anton Mitterer wrote:
> reopen 749795
> I'm reopening this for now, even if the issue is solved from a technical
> point of view (see below why).

AAICS, #749795 talked about bringing this to the security team's
attention, but they never seem to have been CCed.

So the security team may not be aware that a security hole in apt was
recently fixed, that caused apt-get source to not give any indication
when the Release file was lacking a signature.

Whether it's closed in unstable or not, this bug is open still in
stable, and needs to get a CVE assigned, and a DSA issued.

-- 
see shy jo


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

Bug#613169: status

[Joey Hess]

Michael Biebl wrote:
> This bug has been open for a while and is now blocking the removal of
> hal [0]. What's your plan regarding sleepd? Do you still want to port it
> to some newer/other interfaces or should the package be removed from the
> archive?

I have no plans for sleepd.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#742145: openssl: uses only 32 bytes (256 bit) for key generation

[Joey Hess]

Thorsten Glaser wrote:
> Florian Weimer dixit:
> >Historically, the OpenSSL command line tools have been intended for
> >debugging only.
> 
> I disagree, in the case of genrsa and friends anyway.

Me too, and openssl(1ssl) does not mention debugging or not for
production use or give any warnings. Also, openssl genpkey seems
to have the same problem for RSA keys, and so does openssl dsaparam for
DSA keys.

Google has 96k hits for "openssl genrsa". The very second hit is a HOWTO
generate RSA key located on  openssl.org! (The same file is shipped
as /usr/share/doc/openssl/HOWTO/keys.txt in Debian.)

Also, /usr/sbin/make-ssl-cert uses openssl req, and strace shows it
also reading only 32 bytes bits of entropy.

ENTROPY_NEEDED is hardcoded to 32.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#725004: big endian bug

[Joey Hess]

I belive all failed arches are big endian.

The Crypto/Cipher/TripleDES.hs which is failing a roundtrip decrypt . encrypt
test is littered with code that assumes little endian:

word64ToBs :: Word64 -> B.ByteString
word64ToBs = runPut . putWord64le

This has been extensively rewritten in the 0.6.1 release, and I believe
fixed for big endian. haskell-cipher-aes would need to be upgraded
to update to that version, but I see no other obstacles..

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#613169: status

[Joey Hess]

I have a patch in git, but I don't know if it works, or if it will
continue working with newer kernels.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#720714: [Pkg-haskell-maintainers] Bug#720714: Bug#720714: Acknowledgement (will no longer work once rebuilt with linux-libc-dev 3.10.5)

[Joey Hess]

Louis Bettens wrote:
> Done. The patch is being pushed in a couple of minutes. I commited a
> NMU (at least in the changelog) so what's next?

This patch has been included in a new upstream release.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#720714: Acknowledgement (will no longer work once rebuilt with linux-libc-dev 3.10.5)

[Joey Hess]

See https://github.com/audreyt/network-multicast/pull/6 for a patch for
this and also for an ugly file descriptor leak bug.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#720714: will no longer work once rebuilt with linux-libc-dev 3.10.5

[Joey Hess]

Source: haskell-network-multicast
Version: 0.0.7-2
Severity: serious

After rebuilding this package from source, it fails to work:

Prelude Network.Multicast> multicastReceiver "224.0.0.99" 
*** Exception: user error (Network.Socket.setSocketOption: socket option
ReusePort unsupported on this system)

This is apparently because linux-libc-dev has started defining
SO_REUSEPORT, which makes the code go off and try to do something
that the kernel or libc doesn't actually support.

I have filed this bug upstream too:
https://github.com/audreyt/network-multicast/issues/5

I have tested this patch:

- #ifdef SO_REUSEPORT
+ #if defined(SO_REUSEPORT) && ! defined (__linux__)

I would have just uploaded the fix myself, but it tends to take me 1
hour to do anything with packages that use darcs, and I do not currently
have a spare hour.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#718121: gtg-trace: FTBFS: dh_install: libgtg-dev missing files (usr/include/*), aborting

[Joey Hess]

Samuel Thibault wrote:
> It seems dh_auto_install does not run make install at all any more
> here. I don't really understand why: there is a Makefile, and it does
> contain an install rule (it's automake-generated), debian/compat is 8,
> and debian/rules merely contains:

I can look at this in 2 weeks, or you can bisect debhelper, I guess..
9.20130624 would be the most likely version to have introduced recent
breakage in this area.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#718104: bsdiff: FTBFS: Makefile:13: *** missing separator. Stop.

[Joey Hess]

(Did not notice this bug until now, due to the way it was
reassigned to debhelper w/o ccing me.)

I don't think I can revert the change that broke this.
There are no other good approaches for fixing #713257.

To fix this in debhelper, it would need to somehow detect that this
Makefile uses a different make, perhaps by looking for a #!bsdmake, or
checking if MAKE=bsdmake. However, we then have the problem of how
debhelper is supposed to drive bsdmake to determine if the Makefile
contains particular targets. The -s -n --no-print-directory
options it uses for this may not work with other makes. I have little
desire to complicate these commands with support for other makes -- it's
hard enough to make it work reliably with GNU make!

I don't think trying to get GNU make to support BSD make features is
likely to be a prodictive approach. Fixing the few packages that
are affected seems like the most expedient way to me. They could patch
their Makefiles to work with GNU make, or they could override dh_auto_*
with manual calls to the right make command.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#718191: moreutils: vidir loses changes on error

[Joey Hess]

Michael Gold wrote:
> vidir should either reopen the editor on error (maybe with comments at
> the top and above the bad lines) or save a copy of the edited list in
> the working directory.
> 
> I have occasionally encountered this problem after spending a long time
> editing a large directory, and have had to redo my work because of it.
> I'm therefore marking the bug 'grave', although I'm not sure whether
> the severity is meant to cover this kind of metadata loss.

Grave severity means that this is so important that it would be better
to remove moreutils entirely than leave it as-is.

I don't object to fixing this in principle, but that just punctured my
motivation. Patches accepted.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#717456: data loss adding tarball of git-annex repository

[Joey Hess]

Package: git-annex
Version: 4.20130521
Severity: serious

git-annex has a bug that can cause data loss:

http://git-annex.branchable.com/bugs/git_annex_add_removes_file_with_no_data_left/

This probably only affects adding tarballs of git-annex repositories.
Which is not a completely absurd use case.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#717442: debian/rules binary fails to run build target

[Joey Hess]

Package: haskell-devscripts
Version: 0.8.17
Severity: serious

This probably affects many haskell packages, but the one I encountered
it with is haskell-hinotify. Running debian/rules binary fails:

debian/hlibrary.setup copy --builddir=dist-ghc --destdir=debian/tmp-inst-ghc
Installing library in
debian/tmp-inst-ghc/usr/lib/haskell-packages/ghc/lib/hinotify-0.3.2/ghc-7.4.1
hlibrary.setup: Error: Could not find module: System.INotify with any suffix:
["hi"] in the search path: ["dist-ghc/build"]

This turns out to be because the binary target is not running the build
target. Which is policy violation:

  Both `binary-*' targets should depend on the `build' target, or
  on the appropriate `build-arch' or `build-indep' target, if
  provided, so that the package is built if it has not been
  already.

cdbs may be at the root of this bug

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages haskell-devscripts depends on:
ii  cdbs0.4.122
ii  dctrl-tools 2.23
ii  debhelper   9.20130630
ii  dh-buildinfo0.9+nmu1
ii  ghc 7.6.3-3
ii  ghc-haddock 7.6.3-3
ii  hscolour1.20.3-2
ii  html-xml-utils  6.4-1

haskell-devscripts recommends no packages.

haskell-devscripts suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#713257: drawxtl: FTBFS: make[2]: *** No rule to make target `distclean'. Stop.

[Joey Hess]

Daniel Leidert wrote:
> I received the report below. Turns out, that there is a clean target,
> but debuild fails, because there is no distclean target. Could there be
> a mixup or a regression with #706923/#707481?

Only to the extent that before it ignored the -C you have specified,
so make found no Makefile, and no cleaning was done. Which was probably
a bug in your package before.

The actual problem is that this Makefile builds and includes .deps 
the first time it's run, which defeats the code that attempts to detect
if a target exists by running make -s -n and seeing if make says that
would do anything.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#707481: Candidates for removal from testing (2013-06-04)

[Joey Hess]

Seems I confused xgalaga with xgalaga++, which does use dh.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#707481: Candidates for removal from testing (2013-06-04)

[Joey Hess]

Paul Wise wrote:
> Control: severity -1 grave
> Control: reassign -1 debhelper 9.20130518
> Control: affects -1 + src:xgalaga++
> Control: tags -1 - jessie
> 
> The FTBFS bug against xgalaga++ (#707481) is caused by debhelper, it
> builds fine with debhelper 9.20120909 but not with debhelper
> 9.20130518. It appears that debhelper is not able to detect the build
> system any more.

The xgalaga++ rules file does not use dh, nor does it use any dh_auto_*.
So how can detection of build system have anything to do with it?

You need to do better than that for this to be a valid bug report
against debhelper. Even if it were, it's very unlikely it would have RC
severity.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#707505: Bug#707336: Bug#707505: vigor: FTBFS: /bin/mkdir: cannot create directory '/«PKGBUILDDIR»/debian/vigor/usr': No such file or directory

[Joey Hess]

Colin Watson wrote:
> I can work around this.  However, it's a consequence of a debhelper
> change, already reported in #707336.  Since dh_installdirs no longer
> runs, debian/vigor is not created, and so the upstream Makefile's lack
> of 'mkdir -p' trips.

I was just looking at this, and realized that non-debhelper commands may
rely on the directory existing. So, dh creates it when skipping commands
as a temporary workaround (until compat level 10).

dh_auto_install also creates the directory now.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#706187: closed by Joachim Breitner (Bug#706187: fixed in haskell-github 0.7.0-1)

[Joey Hess]

Paul Wise wrote:
> On Fri, 2013-04-26 at 08:51 +, Debian Bug Tracking System wrote:
> 
> >  haskell-github (0.7.0-1) experimental; urgency=low
> >  .
> >* New upstream release (Closes: #706187)
> 
> Thanks, but I think this bug needs to be fixed in wheezy too?

I have uploaded both haskell-github and github-backup to unstable.
Both packages should be suitable for wheezy.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda

[Joey Hess]

Vincent McIntyre wrote:
> I found the string, in po/sublevel1, here's the templates.po
> #. Type: select
> #. Choices
> #: ../choose-mirror-bin.templates.http-in:2001
> #: ../choose-mirror-bin.templates.ftp.sel-in:2001
> msgid "enter information manually"
> msgstr ""
> 
> Is it the case that I need to
> a) give a unique number to the new question in grub-installer/po/templates.pot

A cron job should take care of this, as long as an identical string is
used in the templates file.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda

[Joey Hess]

Gaudenz Steinlin wrote:
> Do you know how the problem can be triggerd. As far as I remember only
> some installation from USB are affected and I don't know if the
> difference between those affected and those unaffected has ever been
> identified. If I know that I'm testing the right test case, I'm willing
> to try your patch.

Well, the patch always prompts with a menu, so essentially you don't
need to reproduce the problem case to test it.

I'd be more concerned about testing it on different architectures.
Particularly ones without a /dev/disk/by-id/

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda

[Joey Hess]

Vincent McIntyre wrote:
> It's entirely possible this patch is not the full resolution of the various
> issues people have reported but I'm posting it to get feedback on the
> approach and get some help with correctly integrating it into d-i.

This adds a new translatable template, which it is far too late in the
release process to get translated. I think this problem could be
finessed by copying the text of the short description and first paragraph of
the grub-installer/bootdev template.
(Ideally into a common template that is SUBSTED into both to avoid bloat.)

There are also some hardcoded user-visible strings embedded in the code,
which need to be a) moved to the template and b) somehow translated
3 months ago. I don't think that "(An entry dialog will appear)" adds
anything to the  $manual_entry string ("Enter device manually").
There is an "enter information manually" string in choose-mirror that
could be copied, with full translations.


device_list() builds a comma-delimited list; it could be that the
description of a device contains a comma (eg, "Foo Corp, Inc. mega super 
drive"),
and so it needs to be sanitized.


+# make sure this question is displayed at least once
+db_fset  grub-installer/choose_bootdev seen false

That is unncessary in d-i; d-i always re-asks seen questions.
(And it's very bad style to ever mess with seen flags, in any use of
debconf. You will cause bugs that are hard to find.)

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#704876: hothasktags: FTBFS: cabal: Command not found

[Joey Hess]

Joachim Breitner wrote:
> If you want to avoid cdbs, I’d be happy to see dh support Haskell, but
> it should use the same building steps as haskell-devscripts now, I’d
> think.

I don't know if it's worth putting in the time to make debhelper support
haskell library packages, but it certianly makes sense for it to
automatically handle packages that simply build binaries from a cabal
file. I hope to see an increasing number of such packages in Debian.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#701593: Bug#702151: RM: haskell-tls-extra/0.4.6.1-1

[Joey Hess]

Attached are minimal patches that seem to work. The haskell-certificate
change is direct from upstream git rev 
a156d857189fc880f7d0a2de3310e750994c766b, 
like vincenthz suggested. The minor haskell-tls-extra change mirrors what's
currently in upstream too.

I've tested using tls-debug's tls-retrievecertificate --verify -c, and
it looks correct both for sites with a valid trust chain
(www.google.com, www.box.com), as well as failing properly for sites
with self-signed and non-valid CAs (dev.mutt.org, munin.varnish-software.com).

The only site it doesn't seem to like that I've found is db.debian.org,
which Chromium says has a valid chain, but this fails for:

joey@wren:~/tmp/tls-debug-0.1.1>dist/build/tls-retrievecertificate/tls-retrievecertificate
 -d db.debian.org --verify -c
connecting to db.debian.org on port 443 ...
## Certificate 1 ##
serial:   98
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"ca.debian.org")),([2,5,4,10],(Printable,"Debian"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"db.debian.org")),([2,5,4,10],(Printable,"Debian"))]
validity: (2013-03-01,31765s,True) to (2014-03-01,31765s,True)
## Certificate 2 ##
serial:   3
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"debian-ad...@debian.org")),([2,5,4,3],(Printable,"ca.debian.org")),([2,5,4,10],(Printable,"Debian"))]
validity: (2008-05-13,33200s,True) to (2018-05-10,33200s,True)
## Certificate 3 ##
serial:   16757532242060383272
issuer:   
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
subject:  
[([1,2,840,113549,1,9,1],(IA5,"hostmas...@spi-inc.org")),([2,5,4,3],(Printable,"Certificate
 
Authority")),([2,5,4,6],(Printable,"US")),([2,5,4,7],(Printable,"Indianapolis")),([2,5,4,8],(Printable,"Indiana")),([2,5,4,10],(Printable,"Software
 in the Public Interest")),([2,5,4,11],(Printable,"hostmaster"))]
validity: (2008-05-13,29276s,True) to (2018-05-11,29276s,True)
### certificate chain trust
chain validity : rejected: CertificateRejectOther "certificate is not allowed 
to sign another certificate"
time validity : accepted

However, the most recent upstream versions of tls-* behave identically,
so if this is a bug, it's a separate one. I've let upstream know.

Can someone get the packages updated with these patches and the binnmus
scheduled?

-- 
see shy jo
diff -ur orig/haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs
--- orig/haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs	2012-05-16 04:30:24.0 -0400
+++ haskell-certificate-1.2.3/Data/Certificate/X509/Ext.hs	2013-03-10 13:58:39.0 -0400
@@ -64,14 +64,19 @@
 		| otherwise   -> extensionGet xs
 	Left _-> extensionGet xs
 
-data ExtBasicConstraints = ExtBasicConstraints Bool
+data ExtBasicConstraints = ExtBasicConstraints Bool (Maybe Integer)
 	deriving (Show,Eq)
 
 instance Extension ExtBasicConstraints where
 	extOID = const [2,5,29,19]
-	extEncode (ExtBasicConstraints b) = [Start Sequence,Boolean b,End Sequence]
-	extDecode [Start Sequence,Boolean b,End Sequence] = Right (ExtBasicConstraints b)
-	extDecode [Start Sequence,End Sequence] = Right (ExtBasicConstraints False)
+	extEncode (ExtBasicConstraints b Nothing)  = [Start Sequence,Boolean b,End Sequence]
+	extEncode (ExtBasicConstraints b (Just i)) = [Start Sequence,Boolean b,IntVal i,End Sequence]
+
+	extDecode [Start Sequence,Boolean b,IntVal v,End Sequence]
+		| v >= 0= Right (ExtBasicConstraints b (Just v))
+		| otherwise = Left "invalid pathlen"
+	extDecode [Start Sequence,Boolean b,End Sequence] = Right (ExtBasicConstraints b Nothing)
+	extDecode [Start Sequence,End Sequence] = Right (ExtBasicConstraints False Nothing)
 	extDecode _ = Left "unknown sequence"
 
 data ExtKeyUsage = ExtKeyUsage [ExtKeyUsageFlag]
diff -ur orig/haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs
--- orig/haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs	2013-01-20 10:49:28.0 -0400
+++ haskell-tls-extra-0.4.6.1/Network/TLS/Extra/Certificate.hs	2013-03-10 14:23:34.0 -0400
@@ -92,7 +92,7 @@
 Just (ExtKeyUsage l) -> elem KeyUsage_keyCertSign l
 Nothing  -> False
 			case extensionGet es of
-Just (ExtBasicConstraints True)
+Just (ExtBasicConstraints True _)

Bug#701593: reversion caused by security chain fix

[Joey Hess]

Package: libghc-tls-extra-dev
Version: 0.4.6.1-1
Severity: serious

The security fix in this release seems to have caused a reversion
which rejects certificates that everything else accepts are valid.

Amoung the certificates now rejected is www.box.com, which is a problem
for me with git-annex. Others may be more interested to see that it now
rejects www.google.com's certificate. :P

Upstream bug report: https://github.com/vincenthz/hs-tls/issues/32

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libghc-tls-extra-dev depends on:
ii  ghc [libghc-time-dev-1.4-3e186]  7.4.1-4
ii  libc62.13-38
ii  libffi5  3.0.10-3
pn  libghc-base-dev-4.5.0.0-c8e71
pn  libghc-bytestring-dev-0.9.2.1-4adca  
ii  libghc-certificate-dev [libghc-certificate-dev-1.2.3-97278]  1.2.3-1+b1
ii  libghc-crypto-api-dev [libghc-crypto-api-dev-0.10.2-4102c]   0.10.2-1+b2
ii  libghc-cryptocipher-dev [libghc-cryptocipher-dev-0.3.5-46e4  0.3.5-1+b1
ii  libghc-cryptohash-dev [libghc-cryptohash-dev-0.7.5-e9a2a]0.7.5-1+b2
ii  libghc-mtl-dev [libghc-mtl-dev-2.1.1-ae9b4]  2.1.1-1
ii  libghc-network-dev [libghc-network-dev-2.3.0.13-6b330]   2.3.0.13-1+b2
ii  libghc-pem-dev [libghc-pem-dev-0.1.1-84ae4]  0.1.1-1+b3
ii  libghc-text-dev [libghc-text-dev-0.11.2.0-a625b] 0.11.2.0-1
ii  libghc-tls-dev [libghc-tls-dev-0.9.5-40f43]  0.9.5-1+b2
ii  libghc-vector-dev [libghc-vector-dev-0.9.1-81be4]0.9.1-2+b1
ii  libgmp10 2:5.0.5+dfsg-2

libghc-tls-extra-dev recommends no packages.

Versions of packages libghc-tls-extra-dev suggests:
pn  libghc-tls-extra-doc   
ii  libghc-tls-extra-prof  0.4.6.1-1

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#665296: Putting the sed snippet into a filename

[Joey Hess]

Marcin Owsiany wrote:
> Thanks for the fast review, please see the revised patch attached.

Applied. I will upload it once the current debhelper gets into testing.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#665296: Putting the sed snippet into a filename

[Joey Hess]

Marcin Owsiany wrote:
> +# 4: either text: shell-quoted sed to run on the snippet. Ie, 
> 's/#PACKAGE#/$PACKAGE/'
> +#or a sub to run on each line of the snippet. Ie sub { 
> s/#PACKAGE#/$PACKAGE/ }

I had not thought about making it operate on each line rather than the
whole file, but I think I like it.

> + } else {

I use the other brace style in debhelper.

> +use base 'Test::Class';

This would add a build dep on libtest-class-perl, it might be easier to
get this into the freeze if any added tests just used Test::More.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#665296: Putting the sed snippet into a filename

[Joey Hess]

Marcin Owsiany wrote:
>  - dh_installxmlcatalogs passing an overly long string to autoscript().
>  
>  I think whatever fix is implemented (unless someone knows an answer to my
>  question above), it will mean a change to dh_installxmlcatalogs. So perhaps
>  this bug should be cloned against xml-core and it should implement its own
>  version of autoscript that is safe for long strings (perhaps just copy
>  autoscript from Dh_Lib and apply the patch below, and remove the extra 
> quoting
>  done in dh_installxmlcatalogs).

Suggestion:

autoscript($package, $script, $filename, sub { s/// });

The 4th parameter being a sub can be detected, and the snippet passed
through it, bypassing sed entirely. Things can migrate over to this new
interface as needed, without possibly breaking the old interface.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#682351: git-annex: build fails because of failing tests

[Joey Hess]

gregor herrmann wrote:
> Solution: set GIT_AUTHOR_NAME _and_ GIT_COMMITTER_NAME in test.hs
> (additionally to EMAIL; or GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL
> instead of EMAIL).

I've applied that patch, thanks.

I don't know that this is actually RC, is building on pbuilder some kind
of release requirement? Any upload to fix this in wheezy would need to
go through t-p-u.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#682351: git-annex: build fails because of failing tests

[Joey Hess]

Motiejus Jakštys wrote:
> Building git-annex in pbuilder on squeeze having backports.debian.org
> repository enabled yields this error:
> Testing 1:blackbox:0:git-annex init   
> Testing 1:blackbox:1:git-annex add:0  
> Cases: 54  Tried: 15  Errors: 0  Failures: 0fatal: No HEAD commit to compare 
> with (yet)
> fatal: No HEAD commit to compare with (yet)

It sort of looks like your build environment has something causing
deletion or loss of parts of /tmp while git-annex's test suite is
running there. 

At least, that's the only hypothesis I can muster that explains
the above, in which a git repository is present for part of two
test cases, and then suddenly loses its HEAD, as well as 
the below, in which a git repository in which git config user.name
and git config user.email have both been run suddenly starts complaining
they were not

> Testing 1:blackbox:1:git-annex add:1  
> Cases: 54  Tried: 16  Errors: 0  Failures: 0
> *** Please tell me who you are.
> 
> Run
> 
>   git config --global user.email "y...@example.com"
>   git config --global user.name "Your Name"
> 
> to set your account's default identity.
> Omit --global to set the identity only in this repository.
> 
> fatal: empty ident  > not allowed

Not to mention all these where git clone fails due to 
directories it should have just created turning up missing:

> Cases: 54  Tried: 17  Errors: 0  Failures: 1fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 18  Errors: 0  Failures: 2fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 19  Errors: 0  Failures: 3fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 20  Errors: 0  Failures: 4fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 21  Errors: 0  Failures: 5fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 22  Errors: 0  Failures: 6fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 23  Errors: 0  Failures: 7fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 24  Errors: 0  Failures: 8fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 25  Errors: 0  Failures: 9fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 26  Errors: 0  Failures: 10fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 27  Errors: 0  Failures: 11fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 28  Errors: 0  Failures: 12fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 29  Errors: 0  Failures: 13fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 30  Errors: 0  Failures: 14fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 31  Errors: 0  Failures: 15fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory
> Cases: 54  Tried: 32  Errors: 0  Failures: 16fatal: Unable to create 
> '/tmp/buildd/git-annex-3.20120614~bpo60+1/.t/tmprepo/.git/annex/index.lock': 
> No such file or directory

Given all this, and given that this version has successfully autobuilt
on all architectures, I respenctfully suggest you investigate what's
eating /tmp in your build environment.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#681347: pkgsel: bussiness card and netinstall, Can't exec "aptitude" after Select & Install Software

[Joey Hess]

reassign 681347 ftp.debian.org

VastOne wrote:
> Package: pkgsel
> Severity: serious
> Tags: d-i

> Can't exec "aptitude": No such file or directory at /usr/bin/debconf-apt-
> progress line 130.  line 2.

aptitude's priority was downgraded to optional, but d-i still uses it to
install security updates. The priority needs to be set back to
important.

-- 
see shy jo



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

Bug#679811: dh_shlibdeps crashes on s390x

[Joey Hess]

Soeren Sonnenburg wrote:
> I am not really sure what you suggest here: ssh into some s390x machine
> and build things manually then ran the dh_shlibdeps?

Well, yes, the bug needs to be reproduced and investigated to see what
is crashing, surely.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#679811: dh_shlibdeps crashes on s390x

[Joey Hess]

Joey Hess wrote:
> You can use dh_shlibdeps -d to get the dpkg-shlibdeps command line,
   -v actually

> run that with -v to get the objdump command line, and chase down which
> program is actually crashing that way.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#679811: dh_shlibdeps crashes on s390x

[Joey Hess]

Soeren Sonnenburg wrote:
> When building shogun dh_shlibdeps crashes with 

> *** glibc detected *** /usr/bin/perl: free(): invalid pointer:
> dpkg-shlibdeps: error: objdump died from signal 6
> dh_shlibdeps: dpkg-shlibdeps -Tdebian/shogun-ruby-modular.substvars
> debian/shogun-ruby-modular/usr/lib/site_ruby/1.9.1/s390x-linux/modshogun.so
> returned exit code 255

Is the objdump program somehow a perl script? Because that's what
seems to be crashing, as called by dpkg-shlibdeps, as called by
dh_shlibdeps. But here objdump is a binary.. Anyway, it's either
objdump or dpkg-shlibdeps that is crashing, and the actual bug may well
be in perl. 

You can use dh_shlibdeps -d to get the dpkg-shlibdeps command line,
run that with -v to get the objdump command line, and chase down which
program is actually crashing that way.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#679596: libghc-github-prof: Should be in contrib

[Joey Hess]

shawn wrote:
> is this still the case, because if so, I would be happy to switch it
> over to using weather.gov and/or some other NOAA source directly for US
> weather. (this is the source for 99.9% of US weather data anyways) 

http://bugs.debian.org/647749

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#679596: libghc-github-prof: Should be in contrib

[Joey Hess]

Joey Hess wrote:
> <http://lists.debian.org/20111204195557.ga11...@gnu.kitenet.net>

This seemed a good opportunity to expand that into a BoF, so I've
submitted this: https://penta.debconf.org/penta/submission/dc12/event/931

classifying and exposing network dependencies

Does youtube-dl belong in contrib if it depends on Youtube.com to
function? What about xfce4-weather-plugin, with its less obvious
dependency on a hardcoded Weather.com API key? What about flickrbackup,
which obviously relies on a specific web site, but in a way that helps
users avoid being locked into that site?

A first step to resolving these questions is agreeing on package (or
debtags) metadata that exposes network API dependencies, and classifies
them along a spectrum from no dependence on specific servers, through
default servers for open protocols, to dependency on proprietary
services.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#679596: libghc-github-prof: Should be in contrib

[Joey Hess]

I actually disagree with the thesis of this bug report. Suppose that
Github went away tomorrow, or was blocked by an oppressive regime, or
similar. github-backup would suddenly have its usefullness *validated*.

Furthermore, it is very much an undecided issue which web-API-dependant
packages belong in main. There was an inconclusive thread about this
topic on debian-legal last December. I direct your attention to my post
to it: 

Given the large number of packages in Debian main that only work with
proprietary network services (youtube-dl, xfce's weather applet, many
many other examples), unless there's an explicit policy MUST to
reference to back up this bug's "serious" severity, it doesn't seem
at all justified to single out haskell-github.

Joachim Breitner wrote:
> Also, if the code was not separated into a separate libray,
> noone would worry.

Or if Gitorious or another github clone chose to clone their API (which
seems very doable). This would then be the same as haskell-hs3[2] or other
S3 libraries, which implemented an Amazon-specific API that is now
cloned by the Internet Archive as well as being part of the OpenStack
standard, with server-side implementations in Debian now.

-- 
see shy jo

[1] This is a dangling footnote from my debian-legal post. :)
I was going to mention there that many general-purpose web browsers
currently in Debian have code that only talks to a single,
proprietary network service. Chromium is a particularly bad offender.
[2] incidentially used by git-annex


signature.asc
Description: Digital signature

Bug#678787: github-backup: FTBFS: build-dependency not installable: libghc-github-dev

[Joey Hess]

forwarded 678787 https://github.com/mike-burns/github/issues/24
tag 678787 help
thanks

Lucas Nussbaum wrote:
> >  sbuild-build-depends-github-backup-dummy : Depends: libghc-github-dev but 
> > it is not going to be installed

I've tried to update libghc-github-dev earlier, but it's been broken by an
update to http-conduit, and I don't know conduit well enough to get it
to build again.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#677076: git-annex: data loss when using git annex uninit from subdirectory

[Joey Hess]

Nicola Chiapolini wrote:
> Dear Maintainer,
> When git annex is run from inside a sub-directory of the repository
> only the files in this directory get resored to real files.
> All other files are still symlinks to a now missing .git/annex directory.
> If this was the only repository, these files are now lost.

Ouch! I've very sorry you had to run into this. I will fix it
immediately, making uninit refuse to run in a subdirectory,
and suggest unannex be used instead in that case.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#672477: dh_strip --dbg-package broken

[Joey Hess]

Ondřej Surý wrote:
> the recent debhelper update broke every dh_strip --dbg-package out there,
> unless of course the .build-id/* is intentional:

Two minutes looking for dh_strip in the changelog and reading bug
#642158 have convinced me that .build_id is intentional. How about you?
Did you do at least 2 minutes investigation before filing a grave bug
report? Did you reach some other conclusion?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> I ask for feedback on this combination of patches. Since the bug is
> assigned to debhelper now, I explicitly pull in the sgml-base
> maintainers (who seem to be MIA).

Right. As I think I've posted before to this bug, I will 
move ahead with the debhelper changes as soon as sgml-base is in
unstable (or perhaps testing).

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#672140: prompts for root passwords on a sudo-only system

[Joey Hess]

Package: policykit-1
Version: 0.104-2
Severity: serious
Tags: d-i

In d-i, it is very easy to set up a system without entering a root
password. d-i sets up sudo, and configures gksu to use it
(by changing an alternative).

On such a system, I was prompted by policykit for the (nonexistant) root
password when network-manager wanted to authenticate me in order to
associate to a wireless network. I assume policykit prompts for the root
password for other things too.

If there is some setting we can make in d-i to new installs to make
policykit use sudo, please let me know, and I will make it. It wouldn't
solve the problem when upgrading existing installs that use sudo, but
it'd be better than nothing.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages policykit-1 depends on:
ii  consolekit 0.4.5-3
ii  dbus   1.5.12-1
ii  libc6  2.13-32
ii  libexpat1  2.1.0-1
ii  libglib2.0-0   2.32.2-1
ii  libpam0g   1.1.3-7
ii  libpolkit-agent-1-00.104-2
ii  libpolkit-backend-1-0  0.104-2
ii  libpolkit-gobject-1-0  0.104-2

policykit-1 recommends no packages.

policykit-1 suggests no packages.

-- no debconf information

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> On Mon, Apr 30, 2012 at 12:24:52PM -0400, Joey Hess wrote:
> > Helmut Grohne wrote:
> > > On the debhelper side it should be enough to remove all remaining calls
> > > to update-catalog and introduce a dependency on the changed sgml-base. I
> > > did not test this thus far.

> There are two places where the central catalog is deleted. I am not
> sure which of them you are talking about:
> 1) During postinst the old snippet removes and recreates the central
>catalog. This behaviour is removed by my debhelper.debdiff.

Ok, so you still want that applied. Was not clear.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> I worked out the sgml-base part of the patch. It will turn the super
> catalog into a symbolic link from /etc/sgml/catalog to
> /var/lib/sgml-base/supercatalog and update the latter file using
> triggers. The loosing of user configuration will persist in all detail
> until packages are built with a fixed version of debhelper. I verified
> that upgrading to my sgml-base nmu and reinstalling docutils-common (a
> caller of update-catalog) works as expected.
> 
> On the debhelper side it should be enough to remove all remaining calls
> to update-catalog and introduce a dependency on the changed sgml-base. I
> did not test this thus far.

Won't dh_installcatalogs also need to be modified to stop deleting the
package's central catalog file on upgrade? Or does this do away with
the "central catalog" thing and just use the super catalog?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> On Thu, Apr 26, 2012 at 06:18:40PM -0400, Joey Hess wrote:
> > This is why I originally recommended that the registration process be
> > converted to use triggers. A [directory full] of catalogs, and a root 
> > catalog
> > file automatically generated from them (which need not be a config file
> > in /etc) is a much cleaner approach.
> 
> This change would be fairly intrusive, but it clearly has its
> advantages. update-catalog would be updated to turn any calls containing
> --super into no-ops. These configuration options are somewhat "burnt" by
> the current prerm and postinst invocations and can no longer be used by
> an administrator in a sane way. /etc/sgml/catalog would be regenerated
> using a new update-catalog --update-super. (I don't think moving the
> file elsewhere is feasible.) 

It certianly seems feasible to convert it to a symlink into /var.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Joey Hess wrote:
> This is why I originally recommended that the registration process be
> converted to use triggers. A file fill of catalogs, and a root catalog
   ^ directory full
> file automatically generated from them (which need not be a config file
> in /etc) is a much cleaner approach.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> It gets even worse. Consider the case where a maintainer removes a
> catalog from an existing package and stops calling dh_installcatalogs.
> Then the root catalog would contain a dangling reference and there
> really is no way to fix this anymore, because our code is never invoked
> again. This probably is precisely the reason for why we currently remove
> and add the catalog. To fix this, we will have to keep removing the
> package catalog from the root catalog in prerm, but remember that we did
> it. In the postinst we will have to add it again, iff we removed it
> before. The big question for me would be: How to transfer this state
> from prerm to postinst?

This is why I originally recommended that the registration process be
converted to use triggers. A file fill of catalogs, and a root catalog
file automatically generated from them (which need not be a config file
in /etc) is a much cleaner approach.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> So we seem to agree that both solutions (present vs. adding --transition
> to sgml-base) are doable and both have their own problems. Are you still
> interested in pushing the transitional code to sgml-base? Your arguments
> have convinced me that it could work. I have not yet updated the patch
> to do that, so please tell me whether you want that change (at least for
> evaluation).

While I'm leaning toward just putting the code in debhelper,
I am worried about another issue in the patch. It makes
update-catalog be called only on new install, not upgrade ([-z "$2"]).
But then, if a catalog is added to an existing package,
update-catalog will not be run. There is a new preinst that
runs update-catalog on upgrade, but only during the transition
to conffiles, so it does not close this hole.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#669156: Illegal bang-pattern (use -XBangPatterns)

[Joey Hess]

Erik de Castro Lopo wrote:
> That brings us to the language-javascript problem. Firstly, we should
> really ask upstream to ship the Lexer.x file from which the Lexer.hs
> file is generated. However the reason they reason they ship the haskell
> source rather than the lexer source is so that its possible to install
> language-javascript using "cabal install". Cabal has one rather severe

They could at least ship both and not build the .hs by default.

> limitation, it cannot reliably install build tools like alex. Firstly
> there is no way to specify a dependency on a build tool, secondly
> cabal install will install it by default in $HOME/.cabal/bin/ and if
> that is not on the user's PATH, language-javascript will not compile.

FWIW, there are ways to use Distribution.Simple to get at the binDir,
which could, at least in theory, be used to find and run programs
installed to it.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#669480: ikiwiki: FTBFS: ImportError: No module named docutils.core

[Joey Hess]

Here's what happens when I try to validate a (100% valid) XHTML 1.0
document, now that w3c-sgml-lib has been changed in a way that breaks
w3c-html-validator:

*** Errors validating html/index.html: ***
Error at line 237, character 28:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 239, character 9:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 253, character 50:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 256, character 9:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 265, character 26:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 267, character 9:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 273, character 16:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 280, character 16:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 282, character 9:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 304, character 16:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 306, character 10:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 317, character 26:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 319, character 9:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 328, character 27:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 335, character 6:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 340, character 27:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 342, character 10:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 347, character 23:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 349, character 10:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 354, character 21:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 356, character 10:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 361, character 21:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 363, character 10:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
"NUTOKENS" and parameter separators allowed
Error at line 373, character 23:  omitted tag minimization parameter can be
omitted only if OMITTAG NO is specified
Error at line 375, character 11:  character ":" invalid: only "CDATA",
"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NAME", "NAMES",
"NMTOKEN", "NMTOKENS", "NOTATION", "NUMBER", "NUMBERS", "NUTOKEN",
   

Bug#669487: pyside: FTBFS: build-dependency not installable: libphonon-dev

[Joey Hess]

Lucas Nussbaum wrote:
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-pyside-dummy : Depends: libphonon-dev but it is not 
> > going to be installed
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.

So more than one of these... perhaps your test run was broken?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#669498: github-backup: FTBFS: build-dependency not installable: libghc-github-dev

[Joey Hess]

Lucas Nussbaum wrote:
> >  sbuild-build-depends-github-backup-dummy : Depends: libghc-github-dev but 
> > it is not going to be installed
> > E: Unable to correct problems, you have held broken packages.

I have no idea what this means. How can it possibly be a bug in
github-backup?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> > In the unlikely event that the admin called it, it would detect that
> > the file was a conffile and not delete it.
> 
> An admin could call update-catalog --transition for a package that was
> not rebuilt with the newer debhelper. In that case harm would still
> happen. Do you have an idea about how to prevent this?

Since this is deleting possibly modified config files on upgrade anyway,
this doesn't seem worth worrying about.

> > I do not see any complexity in a versioned dependency;
> > dh_installcatalogs already adds one.
> 
> It must be a Pre-Depends, since we are using it in preinst.

Ok, that's annoying as each package would need misc:PreDepends added.

In that case, maybe this should be left in debhelper. I am pretty
uncomfortable with it though, especially since it does delete config
files.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: [ping] Re: Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> These were my points.
> 
> On Sat, Jan 07, 2012 at 10:25:17PM +0100, Helmut Grohne wrote:
> > On Sat, Jan 07, 2012 at 02:53:46PM -0400, Joey Hess wrote:
> > > But update-catalog can get new switches that handle the transition, and
> > > debhelper can update the code to use them.
> > 
> > Ok. Let's evaulate what could be changed about update-catalog.
> > 1) package catalog.
> >As per Daniel's request the package catalogs are now created at build
> >time, so update-catalog no longer touches them. The only place we
> >still touch the package catalog is to remove it (being an unowned
> >file in /etc) to transition to a proper configfile. So we would add
> >some update-catalog --transition-catalog to the debhelper preinst. It
> >would have do the magic to detect whether this transition is actually
> >necessary.

> > This --transition-catalog would do harm to the system when invoked by an
> > administrator since it relies on the broken behaviour of debhelper's
> > prerm and the creation of the conffile by the package upgrade.

Your patch already has the preinst calling update-catalog. AFAICS, 
update-catalog could check with dpkg-query if the file is not owned
by a package, and not remove it unless this was the case, and it was
called with --transition. 

In the unlikely event that the admin called it, it would detect that
the file was a conffile and not delete it.

> > Essentially the transitional code that I put into preinst would be moved
> > to update-catalog. I honestly do not see the value in this. In fact it
> > the complexity is even larger since we now have to depend on a newer
> > version of sgml-base

I do not see any complexity in a versioned dependency;
dh_installcatalogs already adds one.

> > and if we really need to apply further fixes we
> > need to change two packages now.

No, you just change sgml-base in a manner consistent with its new interface.
debhelper does not enter this highly hypothetical scenario.

> > Not mentioning the combinatorial
> > explosion of version combinations (of debhelper and sgml-base)

AFAICS the "explosion" results in 4 combinations.

> > Another
> > argument against this move is that it makes removing the transitional
> > code much harder.

Well, it's what, 3 lines? The difference is that it's 3 lines in one
place.

-- 
see shy jo



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

Bug#666901: debhelper needs a "Breaks: automake (<< 1.11.2)"

[Joey Hess]

Adrian Bunk wrote:
> Severity: serious

Inflated. Bug #634741 probably did not affect many packages.
It is up to the indidivual package maintainer to use debhelper
in a way that produces a good package; there are many ways to use
debhelper that produce bad packages, and these are, on the whole,
not RC bugs in debhelper. AKA, bug inflation wastes my time typing this
paragraph.

> With that the build behaves differently depending on what automake
> version is installed.

It's not debhelper's job to ensure that packages always build the same
no matter what versions of build dependencies are installed. Ensuring
that a sane set of build dependencies are installed is the job of the
package maintainer. 

> Please add a "Breaks: automake (<< 1.11.2)" to debhelper to ensure
> that automake supports AM_UPDATE_INFO_DIR=no.

This would only make backports of debhelper impossible to use, unless
someone also backported automake.

It also appears to be a misuse of Breaks. Automake is not broken by the
installation of debhelper. A Breaks field would only cause automake to
be deconfigured, which would not prevent debhelper from using it. The
correct field, if any, is Conflicts.

-- 
see shy jo



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

Bug#665263: Possible other fix?

[Joey Hess]

Paul Gevers wrote:
> Hi,
> 
> I believe you have reverted the solution to bug #660794. As I was hit by
> this bug #665263 as well, I solved it by changing the line in
> dh_usrlocal from:
> my $ebs = $bs x 2; # Escape the backslash from the shell
> to
> my $ebs = $bs; # Escape the backslash from the shell
> and that worked as well.
> 
> I am not sure, and I have not investigated extensively, but maybe you
> can still fix #660794 without the problems of #665263.

Debhelper provides a library, and its old behavior is implicitly an
interface which any number of commands outside of debhelper may rely on.

Personally, I have no desire to break things further.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#659081: haskell-binary

[Joey Hess]

binary is now provided by ghc. Besides causing the file conflict
documented in #659081, having libghc-binary-dev still around causes some
other problems. For one, if a package is built against the binary in
ghc, and libghc-binary-dev is installed, ghc sees a conflict and hides
the package that depends on binary.

Some libraries are currently being built against libghc-binary-dev,
and others against the one in ghc, and these libraries cannot be
used at the same time due to the conflict between the binaries.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#658695: udev-udeb: missing call to input_id

[Joey Hess]

Julien Cristau wrote:
> Hi Marco,
> 
> in the regular udev package, 50-udev-default.rules has
> SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id".  This
> file (and rule) seem to be missing from the udeb, which breaks the gtk
> image (X doesn't get any input devices).

So, users have been reporting that the graphical installer is lacking
mouse/keyboard support for months. It's very good that Julien was able to
track it down.. But now we've known what the fix is for half a month,
and users are *still* reporting the bug. Is something preventing udev
from being uploaded to fix this?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> I agree that the complexity should not reside in debhelper templates.
> However that is already the case. The entire code that is responsible
> for #88010 already is contained in debhelper. It is debhelper's prerm
> that removes the package catalog from the root catalog. And it is
> debhelper's postinst that removes the package catalog file. Those are
> two removals shipped in current debhelper and they are causing the harm.
> One of those removals is done using /bin/rm (out of scope of sgml-base)
> and the other removal is a call to update-catalog --quiet --remove
> --super /etc/sgml/$package.cat. Turning this into a no-op is error prone
> on its own as it might legitimately be invoked that way from a user.

I'm not suggesting that the existing code, as currently present in
package maintainer scripts everywhere, should somehow implement this
transition.

But update-catalog can get new switches that handle the transition, and
debhelper can update the code to use them.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
>  * preinst will do the tricky transition part. If it is called during an
>upgrade and /etc/sgml/$package.cat is not owned by any package (this
>is currently the case), then it fixes up the installation. The old
>prerm will have the package catalog removed from the root catalog, so
>it is readded here. The old postinst would recreate
>/etc/sgml/$package.cat. This file is removed during preinst. The
>advantage of this approach is that the conffile can be installed
>without asking the user. The disadvantage of this approach is that
>we are overwriting user changes one more time.

I don't think it's appropriate to put "tricky transition" code into
debhelper autoscripts, from where it is exploded out to lots of
packages. If it's tricky, it's going to break, and it needs to be in a
centralized location so the breakage can be fixed with one upload.

Also, it's quite likely that other packages also use update-catalog,
without using dh_installcatalogs. So this should be fixed in
update-catalog.

>  There is a debhelper.debdiff attached which implements the above
> description. I have rebuild xml-core using this patched debhelper and
> tried to upgrade and reinstall xml-core. However downgrading xml-core
> and upgrading it again results in a broken installation. Even when
> downgrading a package a conffile stays to be a conffile, so the preinst
> hook is only executed during the first upgrade. After the second upgrade
> the /etc/sgml/$package.cat is left untouched (being a conffile) and
> missing from /etc/sgml/catalog.

It's not clear to me if this is a serious problem with this approach or
not. I will let the maintainer of update-catalog deside when
implementing their solution.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#653840: rootskel-bootfloppy: depends on unavailable klibc-utils-floppy-udeb on ia64

[Joey Hess]

Julien Cristau wrote:
> rootskel-bootfloppy/ia64 unsatisfiable Depends: klibc-utils-floppy-udeb 
> (>= 1.5-2)

This is not a new dependency, it's from 2008 and klibc-utils-floppy-udeb
is not built on ia64.

But why are you trying to use boot floppies, let alone on ia64 anyway?

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

[Joey Hess]

Roger Leigh wrote:
> I think an important point to consider is that /usr would not
> disappear.  It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs.  So no changes
> to --prefix would be needed, and the Debian packages themselves
> could still provide files in /usr.

Didn't the hurd port try this several years ago? My impression was that
they didn't feel it had been worth the pain, perhaps it's not so easy.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#617315: policy /usr/local edge case failure

[Joey Hess]

retitle 617315 policy /usr/local edge case failure
reassign 617315 debian-policy
severity 617315 normal
thanks

Policy requires that creation/removal of directories in /usr/local
never fail, but its example does fail as seen in this bug report.
Apparently the problem is that the chown or chmod could fail.

One approach would be to guard them like this:

if [ ! -e "$dir" ]; then
if mkdir "$dir" 2>/dev/null; then
if chown "$user":"$group" "$dir"; then
chmod "$mode" "$dir" || true
fi
fi
fi

If the chown fails, the directory is left with the wrong user:group,
but it is either root:root, or some other trusted group, like staff, to
which /usr/local is setgid, so that seems ok. Any member of that group
could mkdir /usr/local/foo themselves and get a similar directory.

I'm unsure whether the chmod should only be run once the chown succeeds, or
always be run. If the chmod is widening the permissions (4775), it seems best
to only do that if the directory has the right owner. If it's narrowing the
permissions (0700), it might be better to always do it.

I'm also unsure whether the error messages should be suppressed.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> Good. This would also necessitate a versioned dependency on sgml-base.

Yes, easy since it already uses misc:Depends.

> Do you want a diff for debhelper?

Would be appreciated.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#477751: tackling this bug

[Joey Hess]

Helmut Grohne wrote:
> So what are your thoughts on this?

I haven't considered all the implications... Will the new sgml-base
work ok with the old postinst? With mixtures of the new and old
postinsts?

I'm happy moving ahead with the debhelper changes as soon as sgml-base
is in unstable.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#643950: libgssglue1: Do remove bzip2 compression quickly.

[Joey Hess]

In other words, this needs to be fixed IMMEDIATELY, since this breaks
*all* installations of Debian testing and unstable.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#640874: leave: debian/rules is not a Makefile

[Joey Hess]

Colin Watson wrote:
>   * While it's true that make is largely delegating responsibility to
> another program here, it's a common program used by many packages,
> and so serves to consolidate a lot of boring common code which is a
> fairly standard software virtue.  I'd be hard-pressed to codify
> this, but that does seem different in kind from forking a secondary
> rules implementation local to a single source package simply for the
> purpose of switching language.

If it helps, while I used to agree with Josip, I changed my mind, and dh
is actually what changed it. While dh subverts policy to a certian
extent, policy required it be used in the context of a makefile, and
this led to it using the makefile for configuration via override
targets, which was the single most important development in dh's evolution.
If debian/rules had not remained a makefile, that would not have been
possible, and dh would have a more complex and less flexible configuration.

Since dh is a common idiom, it's not particularly confusing to do this, now:

#!/usr/bin/make -f
%:
debian/myscript $@

Which is probably the simplest way to bring leave into policy compliance.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#640021: Acknowledgement (contains copypasted descriptions of eg, comics without copyright)

[Joey Hess]

There is also a large piece of text about Dirac in another file in
calibre, which ends with "Copyright © Reed Business Information, a
division of Reed Elsevier Inc. All rights reserved."

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#640021: contains copypasted descriptions of eg, comics without copyright

[Joey Hess]

Package: calibre
Severity: serious

While looking in the source for something else, I stumbled upon this:

./recipes/comics_com.recipe:# "Peter is a 
stay-at-home Dad [...]
./recipes/comics_com.recipe:# "Silly family antics 
and goofball humor [...]
./recipes/comics_com.recipe:# "Take an ordinary 
work situation, add a pinch of satire, [...]

These comments are clearly taken from that website, and without copyright,
and are probably too long quotations to be fair use. For example
the second one is a verbatim copy from this page:
http://www.gocomics.com/drabble

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#630163: building all spec files fails: "error: No file attributes configured" (alien also broken)

[Joey Hess]

Package: rpm
Version: 4.9.0-5
Severity: serious

This new version of rpm seems broken at building any spec file
I pass to rpmbuild.

error: No file attributes configured

This happens even if the spec file uses %defattr.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages rpm depends on:
ii  libc6 2.13-5 Embedded GNU C Library: Shared lib
ii  libelf1   0.152-1library to read and write ELF file
ii  libpopt0  1.16-1 lib for parsing cmdline parameters
ii  librpm2   4.9.0-5RPM shared library
ii  librpmbuild2  4.9.0-5RPM build shared library
ii  librpmio2 4.9.0-5RPM IO shared library
ii  librpmsign0   4.9.0-5RPM signing shared library
ii  perl  5.12.3-7   Larry Wall's Practical Extraction 
ii  rpm-common4.9.0-5common files for RPM
ii  rpm2cpio  4.9.0-5tool to convert RPM package to CPI

rpm recommends no packages.

Versions of packages rpm suggests:
ii  alien 8.84   convert and install rpm and other 
pn  elfutils   (no description available)
pn  rpm-i18n   (no description available)

-- debconf information excluded

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#623710: seems fixed?

[Joey Hess]

Tested with binutils 2.21.51.20110523-1 on amd64 and d-i builds
ok with mklibs. Colin also says it's ok on i386.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#625838: cheese dependencies

[Joey Hess]

Simon Renoult wrote:
> Package: cheese
> Version: 2.30.1-2
> Severity: critical
> Tags: d-i

Please don't use the d-i tag for random bug reports that have nothing to
do with the debian installer.

> Justification: breaks unrelated software
> 
> When I try to remove cheese (apt-get autoremove --purge cheese), it deletes
> hundreds of packages in the same time. Here are those packages :

The gnome-desktop-environment metapackage depends on cheese, so by
passing autoremote to apt, you have *told* it to remove this package
and everything that depends on it, and everything that was pulled in my
something that depends on it, ie, all of gnome.

-- 
see shy jo


signature.asc
Description: Digital signature