Bug#286985: ispellcat: initial UTF-8 support

[Guillem Jover]

Hi,

On Thu, Dec 23, 2004 at 07:43:40PM +0100, Agustin Martin wrote:
> On Thu, Dec 23, 2004 at 01:54:54PM +0100, Guillem Jover wrote:

> > Ok here it goes the initial UTF-8 patch. This patch also:
> > 
> >  * Change language descriptions (so they are not improperly displayed
> >on UTF-8 encodings).
> >  * Add some missing OtherChars.
> >  * Change default charsets (to ISO-8859-15).
> >  * Remove redundant and invalid AdditionalChars.
> > 
> > The only problem is that it does not behave properly with the «·»
> > character, it does not consider it part of a word, and I'm not sure
> > if I need to add an Otherchars field in the UTF-8 entry and with what
> > encoding. Agustín what do you think?

> Otherchars refers only to emacs. I do not have a catalan dict available, but
> I suppose it is defined as a stringchar in the base encoding. I will try to
> take a look after Christmas.

I've fixed all stuff Agustín pointed out.
Here's the revised pseudo-changelog. Patch attached.

 * Add initial UTF-8 support.
 * Remove obsolete Pspell-Ispell.
 * Added Aspell-Locales.
 * Change language descriptions.
 * Add some missing OtherChars.
 * Remove redundant and invalid AdditionalChars.

regards,
guillem
diff -Naur ispellcat-0.4.orig/catalan-i.aff ispellcat-0.4/catalan-i.aff
--- ispellcat-0.4.orig/catalan-i.aff2004-02-11 14:48:47.0 +0100
+++ ispellcat-0.4/catalan-i.aff 2005-01-20 18:37:56.0 +0100
@@ -88,6 +88,35 @@
 altstringchar  \"u ü
 altstringchar  \"U Ü
 
+# utf8 encoding.
+
+altstringtype "utf8" "tex" ".txt"
+
+altstringchar@aacute;  á
+altstringchar@Aacute;  Á
+altstringchar@agrave;  à
+altstringchar@Agrave;  À
+altstringchar@eacute;  é
+altstringchar@Eacute;  É
+altstringchar@egrave;  è
+altstringchar@Egrave;  È
+altstringchar@iacute;  í
+altstringchar@Iacute;  Í
+altstringchar@iuml;ï
+altstringchar@Iuml;Ï
+altstringchar@oacute;  ó
+altstringchar@Oacute;  Ó
+altstringchar@ograve;  ò
+altstringchar@Ograve;  Ò
+altstringchar@uacute;  ú
+altstringchar@Uacute;  Ú
+altstringchar@uuml;ü
+altstringchar@Uuml;Ü
+altstringchar@ccedilla;ç
+altstringchar@Ccedilla;Ç
+altstringchar@ntilde;  ñ
+altstringchar@Ntilde;  Ñ
+altstringchar@middledot;   ·
 
 # Relació de flags emprats
 
diff -Naur ispellcat-0.4.orig/debian/aspell-ca.info-aspell 
ispellcat-0.4/debian/aspell-ca.info-aspell
--- ispellcat-0.4.orig/debian/aspell-ca.info-aspell 2005-01-20 
18:15:00.0 +0100
+++ ispellcat-0.4/debian/aspell-ca.info-aspell  2005-01-20 18:11:19.0 
+0100
@@ -1,12 +1,12 @@
-Language: català8 (Catalan 8 bits)
+Language: catala8 (Catalan 8 bits)
 Hash-Name: catala
 Emacsen-Name: catala8
 Casechars: [A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Not-Casechars: [^A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Otherchars: [---'.·]
-Many-Otherchars:
-Additionalchars: àèéëíïîñòóöúüçÁÈÉËIÏÎÑÓÓÖÚÜÇ
+Many-Otherchars: yes
 Additionalchars: ÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇàáãèéëíïîñòóöúüç
 Ispell-Args: -B -d catala
 Extended-Character-Mode: ~list
 Coding-System: iso-8859-1
+Aspell-Locales: ca
diff -Naur ispellcat-0.4.orig/debian/icatalan.info-ispell 
ispellcat-0.4/debian/icatalan.info-ispell
--- ispellcat-0.4.orig/debian/icatalan.info-ispell  2005-01-20 
18:15:00.0 +0100
+++ ispellcat-0.4/debian/icatalan.info-ispell   2005-01-20 18:14:17.0 
+0100
@@ -1,11 +1,11 @@
-Language: català TeX (Catalan Tex)
+Language: catala TeX (Catalan Tex)
 Hash-Name: catala
 Emacsen-Name: catala-tex
 Debconf-Display: no
 Casechars: [A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Not-Casechars: [^A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Otherchars: [---'.·]
-Many-Otherchars:
+Many-Otherchars: yes
 Ispell-Args:-B -d catala
 Additionalchars: ÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇàáãèéëíïîñòóöúüç
 Extended-Character-Mode: ~tex
@@ -17,9 +17,18 @@
 Casechars: [A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Not-Casechars: [^A-ZÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇa-zàáãèéëíïîñòóöúüç]
 Otherchars: [---'.·]
-Many-Otherchars:
+Many-Otherchars: yes
 Additionalchars: ÀÁÃÈÉËÍÏÎÑÒÓÖÚÜÇàáãèéëíïîñòóöúüç
 Ispell-Args: -B -d catala
 Extended-Character-Mode: ~list
 Coding-System: iso-8859-1
-Pspell-Ispell: ca iso8859-1
+
+Language: catala-utf8 (Catalan utf-8)
+Hash-Name: catala
+Emacsen-Name: catala-utf8
+Debconf-Display: no
+Emacs-Display: no
+Jed-Display: no
+Ispell-Args: -B -d catala
+Extended-Character-Mode: ~utf8
+Coding-System: utf-8
diff -Naur ispellcat-0.4.orig/debian/rules ispellcat-0.4/debian/rules
--- ispellcat-0.4.orig/debian/rules 2005-01-20 18:15:00.0 +0100
+++ ispellcat-0.4/debian/rules  2005-01-20 19:01:53.0 +0100
@@ -16,8 +16,10 @@
 
chmod +x debian/strip_mw

Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)

[Guillem Jover]

Hi,

I've been thinking on implementing this for a long time. As
Robert has presented an implementation to the Architecture
handling problem that does not convince me at all, so instead
of just sitting here and criticize his design I've coded mine.

The idea is to introduce architecture aliases, they will only take
effect on the source package and will get expanded when building
the binary package so there's not need to touch major infrastructure
to support this, also they respect current syntax. They can be used
on Build-Depends and friends and on Architecture fields on specific
packages.

The aliases are of the form:

  Alias Example Expansion

  -any  hurd-anyhurd-i386
linux-any   i386 powerpc alpha arm ...
  any- any-i386hurd-i386 kfreebsd-i386 i386 ...

There are two other cases just for consistency:

  linux-   linux-i386  i386
any-any any

I've a added as well a new option (-n normalize) to dpkg-architecture
so Maintainers can use it to get the alias expansions. Try it to see
the results.

regards,
guillem
Package: dpkg
Version: 1.10.26
Author: Guillem Jover <[EMAIL PROTECTED]>
Status: not-applied
Description:
 Implement Debian architecture alias support, and normalization via the new
 dpkg-architecture -n option.
 .
 Will take a virtual arch like -any or any- and expand to all
 available arches. And will also normalize linux- to  for
 consistency.

diff -Naur dpkg-1.10.26/scripts/controllib.pl 
dpkg-1.10.26.alias/scripts/controllib.pl
--- dpkg-1.10.26/scripts/controllib.pl  2005-01-11 17:55:11.0 +0100
+++ dpkg-1.10.26.alias/scripts/controllib.pl2005-01-24 09:21:44.0 
+0100
@@ -79,6 +79,14 @@
 $substvar{'Arch'}= $arch;
 }
 
+sub normalize_archlist {
+my ($archstr) = @_;
+my @archlist = map(split(/\s+/, `dpkg-architecture -n$_`),
+   split(/\s+/, $archstr));
+chomp @archlist;
+return @archlist;
+}
+
 sub substvars {
 my ($v) = @_;
 my ($lhs,$vn,$rhs,$count);
@@ -181,7 +189,7 @@
 my ($package, $relation, $version);
 $package = $1 if ($dep_or =~ 
s/^([a-zA-Z0-9][a-zA-Z0-9+._-]*)\s*//m);
 ($relation, $version) = ($1, $2) if ($dep_or =~ 
s/^\((=|<=|>=|<>?)\s*([^)]+).*\)\s*//m);
-my @arches = split(/\s+/m, $1) if ($use_arch && $dep_or =~ 
s/^\[([^]]+)\]\s*//m);
+my @arches = normalize_archlist($1) if ($use_arch && $dep_or =~ 
s/^\[([^]]+)\]\s*//m);
 if ($reduce_arch && @arches) {
 
 my $seen_arch='';
diff -Naur dpkg-1.10.26/scripts/dpkg-architecture.pl 
dpkg-1.10.26.alias/scripts/dpkg-architecture.pl
--- dpkg-1.10.26/scripts/dpkg-architecture.pl   2005-01-11 17:55:11.0 
+0100
+++ dpkg-1.10.26.alias/scripts/dpkg-architecture.pl 2005-01-24 
09:06:45.0 +0100
@@ -92,6 +92,7 @@
-s print command to set environment variables
-u print command to unset environment variables
-cset environment and run the command in it.
+   -nnormalize Debian architecture
 
 Known Debian Architectures are ".join(", ",keys %archtable)."
 Known GNU System Types are ".join(", ",map ($archtable{$_},keys %archtable))."
@@ -122,6 +123,39 @@
return @list;
 }
 
+sub debian_arch_linux_normalize
+{
+  local ($_) = @_;
+  $_ = "linux-$_" if !/-/;
+  return $_;
+}
+
+sub debian_arch_normalize
+{
+  my ($arch) = @_;
+  my @list;
+
+  if ($arch =~ /^any(-any)?$/) {
+@list = keys %archtable;
+  } elsif ($arch =~ /^any-(.*)/) {
+my $cpu = $1;
+foreach my $a (keys %archtable) {
+  push @list, $a if debian_arch_linux_normalize($a) =~ /-$cpu$/;
+}
+  } elsif ($arch =~ /(.*)-any$/) {
+my $system = $1;
+foreach my $a (keys %archtable) {
+  push @list, $a if debian_arch_linux_normalize($a) =~ /^$system-/;
+}
+  } else {
+$arch =~ s/^linux-//;
+push @list, $arch;
+  }
+
+  return @list;
+}
+
+
 # Set default values:
 
 $deb_build_arch = `dpkg --print-installation-architecture`;
@@ -169,6 +203,7 @@
 
 $req_host_arch = '';
 $req_host_gnu_type = '';
+$req_normalize_arch = '';
 $action='l';
 $force=0;
 
@@ -178,6 +213,9 @@
$req_host_arch = $';
 } elsif (m/^-t/) {
$req_host_gnu_type = &rewrite_gnu($');
+} elsif (m/^-n/) {
+   $req_normalize_arch = $';
+   $action = 'n';
 } elsif (m/^-[lsu]$/) {
$action = $_;
$action =~ s/^-//;
@@ -270,6 +308,9 @@
 } else {
 die "$req_variable_to_print is not a supported variable name";
 }
+} elsif ($action eq 'n') {
+  @arch_list = debian_arch_normalize($req_normalize_arch);
+  print "@arch_list\n";
 }
 
 __END__
diff -Naur dpkg-1.10.26/scripts/dpkg-g

Bug#291939: Bug#268377: Bug#291939: Support for arch aliases

[Guillem Jover]

Hi,

On Mon, Jan 24, 2005 at 11:45:24AM +0100, Goswin von Brederlow wrote:
> Guillem Jover <[EMAIL PROTECTED]> writes:
> > The idea is to introduce architecture aliases, they will only take
> > effect on the source package and will get expanded when building
> > the binary package so there's not need to touch major infrastructure
> > to support this, also they respect current syntax. They can be used
> > on Build-Depends and friends and on Architecture fields on specific
> > packages.
> 
> type-handling already does all you ever want.

No, it does not. And as Robert has explained in another mail it
needs hacks like an autogenerated control file, and use of self
defined "aliases", etc. My patch, what does is integrate that
functionality into the tools that handle debian source packages
so we get that support for free in a clean way. I'll use a more
explicit example this time:

  Source: bochs
  Build-Depends: libasound2-dev [linux-any], libsvga1-dev [linux-any],
 g++-3.4 [linux-m68k]

  Package: sb16ctrl-bochs
  Architecture: any-i386

The linux-m68k is just for consitency, no need to use this, but it
make it clear that the dependency is not for all m68k based ports
(not that we have any, but who knows :), just for the linux based
one.

On another thread, Goswin von Brederlow wrote:
> Could we automatically define some @linux@ or @any-i386@ variables the
> same way shlidbs or other substitutions work?

That's exactly what my patch tries to do, but extending the
recognised normal arches with some aliases that get expaned and
normalized to normal debian archtitectures, the ones the binary
tools can and know how to handle.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291939: Split System/Cpu for architecture handling

[Guillem Jover]

Hi,

On Mon, Jan 24, 2005 at 01:40:03PM +0100, Robert Millan wrote:
> On Mon, Jan 24, 2005 at 10:11:26AM +0100, Guillem Jover wrote:
> > I've been thinking on implementing this for a long time. As
> > Robert has presented an implementation to the Architecture
> > handling problem that does not convince me at all, so instead
> > of just sitting here and criticize his design I've coded mine.
> 
> You say that you my work doesn't convince you, but yet you refuse
> to criticize it. This dessign is not a quick-and-dirty hack, but
> the result of a proposal I started in Nov 2001 (to whose dessign
> nobody objected ever since).

Yeah I meant to criticize it, but then forgot. :> Also I was not
aware of that proposal. Or I cannot recall you telling me every
time I brought out the alias idea. :>

> I brought this here into discussion precisely to get feedback
> about it, so if you have concerns with my patch please explain
> them.

Ok, I see a couple of big problems with your implementation.

* Currently a real Debian architecture is composed of kernel/system +
  cpu and that's a pair of characteristics that cannot and will not
  be decoupled easily from each binary package, the archive structure
  or the tools that handle them. So splitting that info in the source
  package definition just makes things more complicated w/o a reason.
  That information will be merged back anyway when creating the binary
  package. Your current syntax does not make possible to specify that
  a binary package is available just for hurd-i386, linux-i386 and
  linux-alpha, for example. That can be done with the current syntax,
  I think this is a step back. With mine it can be specified just fine.

* The Build-Depends syntax is not well defined as Goswin has pointed
  out, and it have the same problem as the above point, trying to
  decouple an information that it's naturally joined.
  For example you specify your disire to have something like this:

  [cpu: i386 ...] [system: linux ...]

  I assume the "..." specify additional entries, so in that case what
  valid permutations would you choose, and then how would you specify
  convintations that don't include all permutations?

So I see the splitting approach just over complicates things instead
of making them easier to deal with, I think that extending the current
syntax with some new aliases is the saner solution, also the concept is
not as disrruptive in developer minds as the split one. :>

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291939: Bug#268377: Bug#291939: Support for arch aliases

[Guillem Jover]

On Mon, Jan 24, 2005 at 03:27:04PM +0100, Robert Millan wrote:
> On Mon, Jan 24, 2005 at 02:57:09PM +0100, Guillem Jover wrote:
> > That's exactly what my patch tries to do, but extending the
> > recognised normal arches with some aliases that get expaned and
> > normalized to normal debian archtitectures, the ones the binary
> > tools can and know how to handle.
> 
> When Debian was only linux-gnu, one could check DEB_HOST_ARCH for "i386" to do
> something on i386 only.  Currently, if you check DEB_*_ARCH for "i386" you're
> implicitly checking for linux-gnu.  This is why Marcus Brinkmann came up with
> the dpkg-architecture solution in 1999, which splits DEB_*_ARCH in DEB_*_CPU
> and DEB_*_SYSTEM.  My proposal is just a step in this direction.

No, it does not have anything to do with that. Having cpu and system
split to check the build or host system is fine, it's just some
comodity the tools are handing to the maintainer to ease his task.
It's not the same when you have to specify _multiple_ possible target
arches, splitting does not scale.

Also the main concern Marcus had and the only one I think he keeps
today is the confusion some people may have with *_ARCH that 
imply linux.

To address that in a not drastic way we could make the policy deprecate
 arch specifiers and start moving to - for linux.
So we'd use only  as linux- on the binary side, archive and
related tools.

> What you call "normal" debian architectures is just one of the three variables
> that dpkg-architecture can handle (and actualy the less useful one).

It just needs normalization on the linux case and the added
aliases, then it will be as useful as the GNU counterparts on
dpkg-architecture.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291939: Split System/Cpu for architecture handling

[Guillem Jover]

On Mon, Jan 24, 2005 at 03:59:48PM +0100, Robert Millan wrote:
> On Mon, Jan 24, 2005 at 03:26:35PM +0100, Guillem Jover wrote:
> > Ok, I see a couple of big problems with your implementation.
> > 
> > * Currently a real Debian architecture is composed of kernel/system +
> >   cpu and that's a pair of characteristics that cannot and will not
> >   be decoupled easily from each binary package, the archive structure
> >   or the tools that handle them.
> 
> Yes it can.  It's just a three-step transition:
> 
>   - First step is allow dpkg and friends to understand new source format.

That's fine.

>   - Second step is slowly migrating all packages (via Policy).

With your approach, *all* packages need to migrate to the new syntax,
I think that's a bit extreme. From those almost 9k packages a big
majority use 'any' or 'all' specifiers so it's a lot of work and
uploads to finish that migration, that can take years.

With mine you only need to fix the ones that have kludges right
now, not all of them, most will be valid righ now in fact.

>   - Third step is making the change effective wrt DAK.

That would imply changing the archive layout, breaking backward
compatibility, making binary package incompatible with older releases
(BTW how would you guarantee the one release upgrade if you want to
change binary package arch names?). Also the following point:

On another mail, Robert Millan wrote:
>   Cpu: all  / System: all == Architecture: all
>   Cpu: any  / System: any == Architecture: any
>
> Mixed any/all settings are syntacticaly supported, although since dpkg
> or DAK wouldn't support them, Cpu is mandatory for now:
>
>   Cpu: any  / System: all == Architecture: any
>   (e.g. a package with pure-i386 executables like GRUB stage files)
>
>   Cpu: all  / System: any == Architecture: all
>   (e.g. kernel sources or system-specific documentation)
>
> In the future DAK/dpkg should be able to understand these combinations,
> though.

*If* really desired that could be solved easily with my implementation,
just add any-all or all-any when DAK/dpkg can handle that as real
binary packages arches, but ...

... I think the problem is that there are not enough packages to
justify creating (n * cpu) + (n * system) arches to handle those odd
cases, although they would be not real arches as they would get
included in every arch in the same way we handle 'all' packages inside
every 'any' arch. That I suppose is something only ftpmaster can
answer, though.

> >   [...]. Your current syntax does not make possible to specify that
> >   a binary package is available just for hurd-i386, linux-i386 and
> >   linux-alpha, for example. That can be done with the current syntax,
> 
> Yes, but noone has ever done it (if you think someone has, please provide an
> example).  The reason is quite simple:  it doesn't make sense to mix two
> variables that are actualy orthogonal.

I've not done a deep search, just something I recalled, take a look
at fdisk-udeb (alpha amd64 arm hppa i386 ia64 mips mipsel powerpc
hurd-i386 sparc), represent that in your design. (That could have
kfreebsd-i386 as well, once I submit those damn patches. O:> )

> Cpu and System is not naturaly joined.  We decided to join it when starting
> the Hurd port in 1998, but time has proven that this was a wrong decision
> (otherwise, none of us would be looking for a fix).

> It was as early as 1999 when Marcus wrote dpkg-architecture to paliate that
> problem.  But he didn't fix all of it.  My proposal is the remaining part.

No the only problem I see is the assumption that  == linux-
and not any- as would be the logic thing.

> >   I assume the "..." specify additional entries, so in that case what
> >   valid permutations would you choose, and then how would you specify
> >   convintations that don't include all permutations?
> > 
> > So I see the splitting approach just over complicates things instead
> > of making them easier to deal with,
> 
> Again, Cpu and System are orthogonal.  And setting two variables that behave
> exactly like Architecture does (but separately) is quite simple to figure out
> for the maintainer.

No, they are not orthogonal, they are bound, you cannot take a binary
from linux-i386 and install it on kfreebsd-i386, both delimit the
range the binary can apply to, they ABI to which they conform. Also that
you have a package for linux does not mean it should work on all cpus,
some linux ports don't offer the same API and you some times lack
functionality, etc.

> OTOH, having to choose from a list of valid permutations is certainly not the
> easiest for a maintainer to deal with.

It's way logical than restricting him/her to only a s

Bug#291939: Bug#268377: Bug#291939: Support for arch aliases

[Guillem Jover]

On Mon, Jan 24, 2005 at 03:50:17PM +0100, Goswin von Brederlow wrote:
> Guillem Jover <[EMAIL PROTECTED]> writes:
> > On another thread, Goswin von Brederlow wrote:
> >> Could we automatically define some @linux@ or @any-i386@ variables the
> >> same way shlidbs or other substitutions work?
> >
> > That's exactly what my patch tries to do, but extending the
> > recognised normal arches with some aliases that get expaned and
> > normalized to normal debian archtitectures, the ones the binary
> > tools can and know how to handle.
> 
> Except you are also changing the syntax for the control file. That is
> all I see as a negative for this.

Well to fix this in a proper way we have to do _some_ changes, mine
is the solution with less impact and minimal changes, only a little
portion of the archive will change. Robert's implies changing the
whole archive to the new syntax.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#287989: version 0.9.21

[Guillem Jover]

Hi,

[ Bug relative to upgrading directfb to 0.9.21, CCing all dirtectfb
  reverse depending maintainers ]

On Wed, Jan 26, 2005 at 11:37:18AM +0100, Domenico Andreoli wrote:
>   i'm also interested in the new upstream version. i'm working on a
> debian package for my own use. in the next weeks i could upload it,
> if anybody is interested in.

As freeze was approaching I wanted to wait and not break much
packages, there are just 3 packages depending on directfb.

So I'll do a first upload fixing the sysfs bug, and then another one
with a new upstream version to experimental, wait for NEW processing,
and then all you will be able to test and see if packages just build
w/o problems. If all of you agree and RM don't have any problem with
this I'll proceed uploading to sid on a given flag day just after a
katie run, so we break as less as possible.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332598: unace as alternative

[Guillem Jover]

Hi Fabian!

On Thu, Nov 24, 2005 at 11:33:48AM +0100, Fabian Greffrath wrote:
> Marcel Lemke of the unace Team was kind enough to send me the source
> code for unace 2.5 along with an improved license.

Nice work, at least the code is there, but it's not free enough for my
taste.

> Please have a look at the license. I think it makes unace ready for at
> least Debian non-free. It would be great if you considered adopting
> unace 2.5 for Debian!

Well, I'm sorry to disappoint you but I'm not interested in
maintaining non-free software (and that does not mean I don't want
to maintain unace anymore). I'm actually one of those that wanted
to get rid of non-free, and think that by providing software there we
are making a diservice to the Debian users. ;)

Thanks for this work anyway!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#336983: PATCH: Fix for qemu build on PowerPC

[Guillem Jover]

Hi Daniel,

On Mon, Dec 12, 2005 at 05:51:39PM -0800, Daniel Gimpelevich wrote:
> Attached is a patch that was tested on an Ubuntu system. It allows the 
> current sid and dapper (0.7.2-1ubuntu1) sources to build on PowerPC 
> with binutils 2.16.1-2ubuntu6, but not with binutils 
> 2.16.1cvs20051117-1ubuntu1.

I fixed this bug some time ago, I was just waiting until getting qvm86
support integrated. I'll be uploading this week. Thanks for the patch
but it would not be acceptable for Debian if it does not build with
latest packages in sid, and it's not quite relevant what versions are
present in Ubuntu.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#336983: PATCH: Fix for qemu build on PowerPC

[Guillem Jover]

Hi,

On Thu, Dec 15, 2005 at 07:45:23PM -0800, Daniel Gimpelevich wrote:
> The latest binutils in sid is now 2.16.1cvs20051214-1, which should 
> also work. It's the version currently in etch that won't, even with 
> this patch. Without this patch, both versions mentioned above error 
> out. It was meant as a stopgap measure until you could release the next 
> package.

My patch should work on both, but feel free to prove me wrong as I
cannot remember on which version I first got the fix. =)

> If that release is imminent, there is something that I would 
> like to take care of beforehand: I think I have found a bug that causes 
> random garbage to be passed to a syscall under certain circumstances, 
> and I have yet to determine whether the upstream sources or the Debian 
> patches are at fault.

Josh Triplett fixed the signal related support on ppc, if this is
related you could try the latest svn debian dir. Otherwise we can
upload now and once you get the fix a new version can be uploaded
again.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330366: #330366: kded activity disrupts video grabbing despite realtime sched

[Guillem Jover]

Hi,

On Tue, Sep 27, 2005 at 08:40:39PM +0200, Andreas Mohr wrote:
> Package: kdelibs-bin
> Version: 4:3.4.2-3

> I've been having huge trouble doing frame grabbing from my video camera via
> firewire recently. Every ~ 20 seconds a frame got dropped.
> And this all despite running a -ck kernel with dvgrab running in SCHED_ISO,
> which should normally avoid any and all frame drops quite easily.

I've found abnormal disk activity, even when the box was supposedly
not doing anything. I've a kernel built with:

  CONFIG_PREEMPT=y
  CONFIG_PREEMPT_BKL=y

> Is there a way to improve kded to have less activity within one burst?

Can you check if stopping the KDED Media Manager in:

  Control Center -> KDE Components -> Service Manager

makes any difference (it made for me)? It may help narrow down where
the problem comes from, and if your issue is similar to mine.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#343888: svgalib: FTBFS on amd64: /vm86.h:8:3: error: #error This header is not available for x86_64

[Guillem Jover]

On Fri, Jan 06, 2006 at 07:32:36PM +0100, Kurt Roeckx wrote:
> On Fri, Jan 06, 2006 at 08:19:09PM +0200, Guillem Jover wrote:
> > I'm packaging a new upstrem release, and was checking if lrmi code is
> > built on anything != ia32, and it's not, double checked by building it
> > on pergolesi.
> 
> If you tries this on pergolesi, I hope your tried with the proper
> chroot?  All chroots are 32 bit except amd64-sid-pure or
> something.

*blush* I built it on the default 32 bit env. But as the code I was
looking at only was building when != i386, and checking uname on the
default env everything matched. O:)

> Of course I can reproduce this.  Nothing has changed when it
> comes to vm86().

Well I was not expecting anything to change regarding vm86. I was
expecting it to not build it at all. I've just found where it's
hardcoded to build lrmi, I'll fix that for next upload. Sorry for
the mess.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#347313: [Fwd: Log for successful build of inetutils_2:1.4.3+20051212-2 (dist=unstable)]

[Guillem Jover]

severity 347313 wishlist
thanks

Hi dann,

On Mon, Jan 09, 2006 at 05:58:59PM -0700, dann frazier wrote:
> Package: inetutils
> Version: 2:1.4.3+20051212-2
> Severity: important
> Tags: patch

> Our automated buildd log filter[1] detected a problem that will cause
> your package to segfault on architectures where the size of a pointer is
> greater than the size of an integer, such as ia64.

This part of inetutils is not used for any package, so thus I'm lowering
the severity. I'm going to apply the fix anyway and fwd to upstream.
Thanks for those checks though and the patches. =)

> Looks like this part of the fix for #318752 got dropped.

Yeah, sorry about that, I just missed that part from the rejected
chunks. I'll be uploading shortly to fix the FTBSF...

> [1]http://people.debian.org/~dannf/check-implicit-pointer-functions

I'll use it in the future, before uploading!

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#344964: shadow: [INTL:ca] Updated Catalan debconf template

[Guillem Jover]

Package: shadow
Version: 1:4.0.13-7
Severity: wishlist
Tags: l10n patch

Hi,

Attached the Catalan debconf translation.

regards,
guillem
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
msgid ""
msgstr ""
"Project-Id-Version: shadow 1:4.0.13-7\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2005-10-22 08:58+0200\n"
"PO-Revision-Date: 2005-12-28 03:01+0200\n"
"Last-Translator: Guillem Jover <[EMAIL PROTECTED]>\n"
"Language-Team: Catalan \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: password
#. Description
#: ../passwd.templates:21
msgid "Root password:"
msgstr "Contrasenya de root:"

#. Type: password
#. Description
#: ../passwd.templates:21
msgid ""
"You need to set a password for 'root', the system administrative account. A "
"malicious or unqualified user with root access can have disastrous results, "
"so you should take care to choose a root password that is not easy to guess. "
"It should not be a word found in dictionaries, or a word that could be "
"easily associated with you."
msgstr ""
"Necessiteu definir una contrasenya per a «root», el compte d'administració "
"del sistema. Un usuari maliciós o no qualificat amb accés de root podria "
"aportar conseqüències desastroses, per tant heu de triar una contrasenya de "
"root que no sigui fàcil d'endevinar. No ha de ser una paraula del diccionari "
"o una paraula que pugui ser fàcilment associada a vosaltres."

#. Type: password
#. Description
#: ../passwd.templates:21
msgid "Note that you will not be able to see the password as you type it."
msgstr "Tingueu en compte que no veureu la contrasenya mentre la teclejeu."

#. Type: password
#. Description
#: ../passwd.templates:35
msgid ""
"Please enter the same root password again to verify that you have typed it "
"correctly."
msgstr ""
"Si us plau introduïu la mateixa contrasenya de root un altre cop per a "
"verificar que l'heu teclejada correctament."

#. Type: boolean
#. Description
#: ../passwd.templates:42
msgid "Create a normal user account now?"
msgstr "Voleu crear ara un compte d'usuari normal?"

#. Type: boolean
#. Description
#: ../passwd.templates:42
msgid ""
"It's a bad idea to use the root account for normal day-to-day activities, "
"such as the reading of electronic mail, because even a small mistake can "
"result in disaster. You should create a normal user account to use for those "
"day-to-day tasks."
msgstr ""
"És una mala idea usar el compte de root per a les activitas quotidianes, "
"tals com llegir el correu electrònic, perque tan sols una petita errada pot "
"resultar un desastre. Heu de crear un compte d'usuari que podreu usar per a "
"aquestes tasques quotidianes."

#. Type: boolean
#. Description
#: ../passwd.templates:42
msgid ""
"Note that you may create it later (as well as any additional account) by "
"typing 'adduser ' as root, where  is an user name, like "
"'imurdock' or 'rms'."
msgstr ""
"Tingueu en compte que podeu crear-lo després (de la mateixa manera que "
"qualsevol altre compte) teclejant «adduser » com a root, on "
" és quelcom semblant a «imurdock» o «rms»."

#. Type: string
#. Description
#: ../passwd.templates:54
msgid "Full name for the new user:"
msgstr "Nom complet pel nou usuari:"

#. Type: string
#. Description
#: ../passwd.templates:54
msgid ""
"A user account will be created for you to use instead of the root account "
"for non-administrative activities."
msgstr ""
"Es crearà un compte d'usuari per a ser usat en comptes del compte de «root» 
"
"per a tasques no administratives."

#. Type: string
#. Description
#: ../passwd.templates:54
msgid ""
"Please enter the real name of this user. This information will be used for "
"instance as default origin for emails sent by this user as well as a

Bug#344966: debconf: [INTL:ca] Upstream and Debian Catalan po updates

[Guillem Jover]

Package: debconf
Version: 1.4.66
Severity: wishlist
Tags: l10n patch

Hi,

Attached the updated po files for upstream and debian parts.

regards,
guillem
# Debconf Catalan Translation
# Copyright © 2001, 2002, 2004, 2005 Free Software Foundation, Inc.
# This file is distributed under the same license as the debconf package.
# Jordi Mallach <[EMAIL PROTECTED]>, 2001, 2002, 2004, 2005.
# Guillem Jover <[EMAIL PROTECTED]>, 2005.
#
msgid ""
msgstr ""
"Project-Id-Version: debconf 1.4.66\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2005-12-25 10:47+\n"
"PO-Revision-Date: 2005-12-28 03:29+0200\n"
"Last-Translator: Guillem Jover <[EMAIL PROTECTED]>\n"
"Language-Team: Catalan \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../Debconf/AutoSelect.pm:76
#, perl-format
msgid "falling back to frontend: %s"
msgstr "s'està provant ara la interfície: %s"

#: ../Debconf/AutoSelect.pm:84
#, perl-format
msgid "unable to initialize frontend: %s"
msgstr "no s'ha pogut iniciar la interfície: %s"

#: ../Debconf/AutoSelect.pm:90
#, perl-format
msgid "Unable to start a frontend: %s"
msgstr "No s'ha pogut iniciar una interfície: %s"

#: ../Debconf/Config.pm:130
msgid "Config database not specified in config file."
msgstr ""
"La base de dades de configuracions no està especificada en el fitxer de "
"configuració."

#: ../Debconf/Config.pm:134
msgid "Template database not specified in config file."
msgstr ""
"La base de dades de plantilles no està especificada en el fitxer de "
"configuració."

#: ../Debconf/Config.pm:139
msgid ""
"The Sigils and Smileys options in the config file are no longer used. Please "
"remove them."
msgstr ""
"Les opcions «Sigils» i «Smileys» en el fitxer de configuració ja no "
"s'utilitzen. Si us plau, elimineu-les."

#: ../Debconf/Config.pm:153
#, perl-format
msgid "Problem setting up the database defined by stanza %s of %s."
msgstr ""
"Ha hagut un problema en configurar la base de dades definida per l'estrofa %"
"s de %s."

#: ../Debconf/Config.pm:228
msgid ""
"  -f,  --frontend\t\tSpecify debconf frontend to use.\n"
"  -p,  --priority\t\tSpecify minimum priority question to show.\n"
"   --terse\t\t\tEnable terse mode.\n"
msgstr ""
"  -f,  --frontend\t\tEspecifica la interfície de debconf a usar.\n"
"  -p,  --priority\t\tEspecifica la prioritat mínima de preguntes a mostrar.\n"
"   --terse\t\t\tHabilita el mode concís.\n"

#: ../Debconf/Config.pm:308
#, perl-format
msgid "Ignoring invalid priority \"%s\""
msgstr "S'està descartant la prioritat «%s» invàlida"

#: ../Debconf/Config.pm:309
#, perl-format
msgid "Valid priorities are: %s"
msgstr "Les prioritats vàlides són: %s"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Multiselect.pm:31
#: ../Debconf/Element/Editor/Select.pm:31
msgid "Choices"
msgstr "Opcions"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Boolean.pm:36
#: ../Debconf/Element/Editor/Boolean.pm:59
#: ../Debconf/Element/Teletype/Boolean.pm:28
msgid "yes"
msgstr "sí"

#: ../Debconf/Element/Editor/Boolean.pm:30
#: ../Debconf/Element/Editor/Boolean.pm:39
#: ../Debconf/Element/Editor/Boolean.pm:62
#: ../Debconf/Element/Teletype/Boolean.pm:29
msgid "no"
msgstr "no"

#: ../Debconf/Element/Editor/Multiselect.pm:32
msgid ""
"(Enter zero or more items separated by a comma followed by a space (', ').)"
msgstr ""
"(Introduïu zero o més elements separats per una coma seguida d'un espai (', "
"').)"

#: ../Debconf/Element/Gnome.pm:183
msgid "_Help"
msgstr "A_juda"

#: ../Debconf/Element/Gnome.pm:185
msgid "Help"
msgstr "Ajuda"

#: ../Debconf/Element/Gnome/Note.pm:52
msgid "Save (mail) Note"
msgstr "Desa (envia per correu) la nota"

#: ../Debconf/Element/Gnome/Note.pm:53
msgid "Debconf was asked to save this note, so it mailed it to you."
msgstr ""
"Es va demanar a Debconf que desés aquesta nota, així que vos l'ha enviat per "
"correu."

#: ../Debconf/Element/Gnome/Note.pm:55
msgid "Information"
msgstr "Informació"

#: ../Debconf/Element/Gnome/Note.pm:56
msgid "The note has been mailed."
msgstr "La nota s'ha enviat per correu."

#: ../Debconf/Element/Gnome/Note.pm:60
msgid &q

Bug#336983: qemu: FTBFS on PowerPC

[Guillem Jover]

Package: qemu
Version: 0.7.2-1
Severity: serious

Hi,

AngryPorter:

  Your package sucks it does not build on PPC anymore!

ShamefulMaintainers:

  Sorry about that, we already know about the problem, it's most
  probably the PPC linker script patch that Guillem reverted on
  last upload. We'll fix that RSN! Thanks for your report!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339693: Would like svgalib_helper module source package

[Guillem Jover]

found 339693 1.9.23-1
tags 339693 wontfix
thanks

Hi,

On Thu, Nov 17, 2005 at 04:34:17PM -0800, [EMAIL PROTECTED] wrote:
> Package: svgalib
> Severity: wishlist

Please, when reporting bugs, specify the version number so that the
BTS can use the versioning magic to keep track of when the bugs were
fixed. Or use reportbug, which should Do The Right Thing (tm).

> I'd like to have a svgalib-modules-source package that contains
> svgalib_helper, buildable with kernel-package.

Well, I'm not going to package it until it's secure, and the current
version it's not, at all (arbitrary io port writting). So I'd
recommend you consider disabling it in your boxes if you have built
it from source.

(I'll remove the wontfix tag once it's secure again).

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339693: svgalib: isn't building with linux 2.6.14 anyway

[Guillem Jover]

On Thu, Nov 17, 2005 at 06:47:38PM -0800, [EMAIL PROTECTED] wrote:
> Package: svgalib
> Followup-For: Bug #339693

> svgalib_helper has the unknown symbol io_remap_page_range which no
> longer exists in the linux source. So I'll wait until it gets around to
> letting itself get packaged.

Right, I fixed that locally when testing it, but didn't put the patch
in the package...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339870: openhackware: FTBFS: unrecognized option `-mregnames'

[Guillem Jover]

package openhackware
severity 339870 normal
retitle 339870 openhackware: should not try to build on !powerpc environments
merge 339870 322300
thanks

On Sat, Nov 19, 2005 at 01:55:43PM +0100, Roland Stigge wrote:
> Package: openhackware
> Version: 0.4.1-1
> Severity: serious

> building the package openhackware in a clean sid build environment
> (with pbuilder) on i386 results in:

It's supposed to only be buildable on a ppc environment, be it native
or crosscompiled. The problem is that right now we don't have a clear
way to specify this kind of build requirement.

What I can do is ask for an addition to Packages-arch-specific so that
buildd (using P-a-s should not try this package if not on ppc), and
then add checks to the package itself to bail out sooner and give a
proper error message.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339916: RM: gnumach1 -- RoM; superseded by gnumach

[Guillem Jover]

Package: ftp.debian.org

Hi,

The source package gnumach1 was supposed to be what the gnumach one
has now, and gnumach switch to the cvs HEAD, this has never happened
as HEAD is unmaintained and all development goes to a branch.

So please remove this package from the archive. It also has a
build dependency on gcc-2.95 and it's blocking its removal.

[I'm not listed on the Maintainer field, because I didn't get to do
 any upload, but I'm the de facto maintainer for gnumach and mig. ]

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#340089: mc: Replace unarj invokation with arj, and suggest it

[Guillem Jover]

Package: mc
Version: 1:4.6.1-1
Tags: patch

Hi,

The compatibility package unarj is not in sid anymore, and we have the
full free arj package instead. So when trying to list an .arj archive
mc complains that it cannot find unarj, even if arj is installed. Also
there's no Suggests about that.

Attached a patch that fixes both.

regards,
guillem
diff -Naur mc-4.6.1/debian/control mc-4.6.1.new/debian/control
--- mc-4.6.1/debian/control 2005-11-20 22:07:57.0 +0200
+++ mc-4.6.1.new/debian/control 2005-11-20 22:06:11.0 +0200
@@ -9,7 +9,7 @@
 Package: mc
 Architecture: any
 Depends: ${shlibs:Depends}
-Suggests: perl, mime-support, zip, unzip, bzip2, lynx
+Suggests: perl, mime-support, zip, unzip, bzip2, arj, lynx
 Conflicts: mc-common, suidmanager (<< 0.52)
 Replaces: mc-common, manpages-pl (<= 20030210)
 Description: midnight commander - a powerful file manager
diff -Naur mc-4.6.1/lib/mc.ext.in mc-4.6.1.new/lib/mc.ext.in
--- mc-4.6.1/lib/mc.ext.in  2005-07-23 19:51:15.0 +0300
+++ mc-4.6.1.new/lib/mc.ext.in  2005-11-20 22:03:50.0 +0200
@@ -142,7 +142,7 @@
 # arj
 regex/\.a(rj|[0-9][0-9])$
Open=%cd %p#uarj
-   View=%view{ascii} unarj l %f
+   View=%view{ascii} arj l %f
 
 # ha
 regex/\.([Hh][Aa])$

Bug#339870: openhackware: FTBFS: unrecognized option `-mregnames'

[Guillem Jover]

severity 339870 normal
thanks

Hi,

On Sat, Nov 19, 2005 at 06:01:39PM +0100, Roland Stigge wrote:
> # The package doesn't build on the Architecture (all) it it declared for
> Guillem Jover wrote:
> > > building the package openhackware in a clean sid build environment
> > > (with pbuilder) on i386 results in:

> > It's supposed to only be buildable on a ppc environment, be it native
> > or crosscompiled. The problem is that right now we don't have a clear
> > way to specify this kind of build requirement.

> As p2 explained, the package is clearly "Architecture: powerpc". The
> current "Architecture: all" is definitely broken.

Well and as I've said, I disagree. After requesting it, openhwackware
is now on Packages-arch-specific, so if you want to build arch:all
packages configure your build daemon properly. I'll close this bug
once I add a note on when building on the wrong environment.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#340795: libocc0-dev: Still depends on old C++ ABI lib, making openc++ uninstallable

[Guillem Jover]

Package: libocc0-dev
Version: 2.8-7
Severity: serious

Hi,

While doing the second C++ lib transition you forgot to rename the
dependency on libocc0c2 to libocc0c2a in libocc0-dev, making openc++
uninstallable.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#304983: Provide static library

[Guillem Jover]

Hi,

On Thu, Jun 09, 2005 at 10:42:01PM +0200, Matthijs Mohlmann wrote:
> Here a patch to add the static libraries to the -dev packages.

There was no need to send this patch, I wrote it already. ;)
The problem on last upload was that it broke when enabling static
libraries, so I postponed it for later hunting. It seems to work
now again, so I'll include them on next upload. Oh and there's no
need to ask for shared, they are built by default.

Thanks anyway for the prodding.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#304983: Bug #304983 - Provide static library

[Guillem Jover]

Hi,

On Sat, May 28, 2005 at 04:17:28PM +0200, [EMAIL PROTECTED] wrote:
> Splashy is a replacment in user land for the kernel graphic boot 
> embellishments.
> We use directfb though an issue arises : directfb is in /usr
> which some user have in a separate partition not available until
> half the boot is done. Thus the need for a full static build of
> directfb .

Nice!

> Please give us your point of view : would you include the static
> build in your packages or should we ship with our own build of
> them ?

I wanted to upload a newer release to experimental this weekend and
when I tried to enable the static build it broke so I just decided
to upload and incrementally fix the package. At least now 0.9.22 is
packaged.

I'll include static libs on next upload, most probably.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#311877: INTL:vi

[Guillem Jover]

Hi,

On Sat, Jun 04, 2005 at 11:16:46AM +0930, Clytie Siddall wrote:
> Package: gpm
> Version: 1.19.6-20
> Severity: minor
> Tags: l10n, patch
> 
> The Vietnamese translation for debconf: gpm

Thanks! this is the first Vietnamese translation I get on any of the
packages I (co-)maintain! =)

I've fixed some space indentation problems, and I've commited the po
file into our svn repo.

regrads,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#147462: test package 1.20.1 made but ...

[Guillem Jover]

Hi,

On Fri, Apr 22, 2005 at 12:47:52AM -0500, Peter Samuelson wrote:
> 
> [Osamu Aoki]
> > I was successful compiling 1.20.1 into deb packages under sid with few
> > chenges.  (Please not I am not claiming successful packaging)
> 
> Thanks, I'll take a look at your work.  We're basically waiting on the
> sarge release to switch to 1.20.x.  This might or might not have been a
> good idea in hindsight, given the length of the sarge release.

We already have an initial attempt to package 1.20.x, it was done by
Joshua Kwan and it's in the svn repo:



I'm not sure of its state though, we'll have to recheck and remerge
most of our latest changes.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#306034: gpm: [INTL:pt_BR] Please consider adding the attached debconf template translation

[Guillem Jover]

Hi,

On Sat, Apr 23, 2005 at 05:43:05PM -0300, Rodrigo Tadeu Claro wrote:
> Package: gpm
> Severity: wishlist
> Tags: patch l10n
> 
> Please consider using the attached gpm Brazilian Portuguese (pt_BR)
> debconf template translation. It was properly checked against errors using
> the msgfmt utility from gettext package as can be see bellow :
> 
> [EMAIL PROTECTED]:~/debian-traducoes/gpm$ msgfmt -o /dev/null -v pt_BR.po
> 20 mensagens traduzidas.
> [EMAIL PROTECTED]:~/debian-traducoes/gpm$

I've checked the translation and it had few errors:

There was a line using strange "·" characters instead of spaces. I've
fixed that. The mouse types translation was not indented. And that's
minor, but the the lines were longer than 80 chars.

  msgid "Enter 'none' to turn repeating off."
  msgstr "Deixe em branco para repetir a configuração."

This one is wrong, keeping the field empty is not the same as putting
"none".

There was a line ending with "... seu" and the next one "sistema ...",
that will became "... seusistema ..." as they are logical lines and if
there's no space there they will be joined. Fixed that as well.

So please provide us with a fixed translation for the none string,
I've included the initial fixed version in the subversion repo.

> Also, it's bziped for size optimization.

By bzipping you force your mail client to use base64 or similar
encodings that make the file way greater than it was.

Thanks for the translation!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#35970: gnumach hangs because of Linux 2.0.36 adaptec drivers

[Guillem Jover]

Hi Santiago,

Can you reproduce #35970 with the latest gnumach packages?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309876: 'man arjdisp' typo: "airchive"

[Guillem Jover]

Hi,

On Fri, May 20, 2005 at 04:15:37AM -0400, A Costa wrote:
> Package: arj
> Version: 3.10.21-3
> Severity: minor
> Tags: patch

> Found a typo in '/usr/share/man/man1/arjdisp.1.gz', see attached '.diff'.

You could have filed only one bug report for both minor typo errors.

But anyway thanks for the report and patch!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#268377: Bug#291939: Support for arch aliases (Was: Split System/Cpu for architecture handling)

[Guillem Jover]

On Tue, Jan 25, 2005 at 12:05:34AM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 24 Jan 2005, Guillem Jover wrote:
> > The idea is to introduce architecture aliases, they will only take
> [...]
> 
> > I've a added as well a new option (-n normalize) to dpkg-architecture
> > so Maintainers can use it to get the alias expansions. Try it to see
> > the results.
> 
> The (only) problem I can see with this is that, should we add or remove a
> new arch to an alias, you have to recompile everything to be completely in
> sync.

Ideally it should match with target system-cpu and not have a list of
everything possible. See below.

> This can be fixed by keeping the alias somewhere, instead of just expanding
> it everywhere.

Yes, well my implementation expands the aliases but only internally,
you only get the relevant target dependencies when building. Also
exposing the expansions (via -n) is not wise. I think a better
implementation would be to just match the aliases the same way
it's currently done with the "any" virtual arch.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#293426: viewcvs: split log info from file content so it can be distinguished

[Guillem Jover]

Package: viewcvs
Version: 0.9.2+cvs.1.0.dev.2004.07.28-1.4
Severity: wishlist
Tags: patch

Hi,

This trivial patch inserts a line so the log info and the file
content are separated and thus cannot be confused.

regards,
guillem
diff -Naur viewcvs-0.9.2+cvs.1.0.dev.2004.07.28.orig/templates/markup.ezt 
viewcvs-0.9.2+cvs.1.0.dev.2004.07.28/templates/markup.ezt
--- viewcvs-0.9.2+cvs.1.0.dev.2004.07.28.orig/templates/markup.ezt  
2004-07-19 10:49:39.0 +0200
+++ viewcvs-0.9.2+cvs.1.0.dev.2004.07.28/templates/markup.ezt   2005-02-03 
09:49:01.0 +0100
@@ -47,6 +47,8 @@
 [end]
 
 
+
+
 [markup]
 
 [include "include/footer.ezt"]

Bug#293950: typo error for natsemi driver in debian/rules

[Guillem Jover]

tags 293950 pending
thanks

Hi,

On Mon, Feb 07, 2005 at 12:40:27AM +, Regis Boudin wrote:
> Package: gnumach
> Version: 20040915.dfsg.1-1

> I installed a Hurd system yesterday on my laptop, and everything went
> smoothly appart from a lack of support for my ethernet card, based on
> a natsemi controller. It comes from a typo error in the debian/rules
> file.
> Line 72 contains --enable-natsami, which needs to be replaced by
> --enable-natsemi.
> I tried the modification locally and the support was present.

The fix is now ont the subversion repo, will be in next upload.

Thanks for the report!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#300089: /usr/bin/ppmd -> PPMd symlink

[Guillem Jover]

Hi,

On Thu, Mar 17, 2005 at 03:51:41PM +, Justin B Rye wrote:
> Package: ppmd
> Version: 9.1-10
> Severity: wishlist

> I do "aptitude install ppmd"; I glance at "man ppmd":
> 
>  SYNTAX
>   ppmd  [switches] 
> 
> but when I try "ppmd e testfile", of course I get a "command not
> found" - it's /usr/bin/PPMd.  This is confusing for users accustomed
> to the unix "keep it lowercase" philosophy.

Yes, that's certainly something that annoyed me alot once I toke over
the package, and wanted to rename it (via a transition), but then
forgot. :)

> Given that the PPM part just stands for partial pattern matching,
> and given that even Lempel, Ziv, Wheeler, Burroughs etc routinely
> lose their capital letters on the commandline, it would be nice if a
> symlink was provided - compare:
> 
> /usr/bin/abiword -> AbiWord
> /usr/bin/bitchx -> BitchX

Yes, I'll do that on the next upload. Thanks!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#316026: shadow: [INTL:ca] Update catalan translation

[Guillem Jover]

Package: shadow
Version: 1:4.0.3-35
Severity: wishlist
Tags: l10n patch

Hi,

Attached the updated Debian Catalan po translation.

regards,
guillem

PS: Sorry about the delay, but the country was paralized with
Juhannus. =)
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
msgid ""
msgstr ""
"Project-Id-Version: shadow 1:4.0.3-35\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2005-06-17 18:47+0200\n"
"PO-Revision-Date: 2005-06-23 00:30+0300\n"
"Last-Translator: Guillem Jover <[EMAIL PROTECTED]>\n"
"Language-Team: Catalan \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: password
#. Description
#: ../passwd.templates:3
msgid "Root password:"
msgstr "Contrasenya de root:"

#. Type: password
#. Description
#: ../passwd.templates:3
msgid ""
"You need to set a password for 'root', the system administrative account. A "
"malicious or unqualified user with root access can have disastrous results, "
"so you should take care to choose a root password that is not easy to guess. "
"It should not be a word found in dictionaries, or a word that could be "
"easily associated with you."
msgstr ""
"Necessiteu definir una contrasenya per a «root», el compte d'administració "
"del sistema. Un usuari maliciós o no qualificat amb accés de root podria "
"aportar conseqüències desastroses, per tant heu de triar una contrasenya "
"de root que no sigui fàcil d'endevinar. No ha de ser una paraula del "
"diccionari o una paraula que pugui ser fàcilment associada a vosaltres."

#. Type: password
#. Description
#: ../passwd.templates:3
msgid "Note that you will not be able to see the password as you type it."
msgstr "Tingueu en compte que no veureu la contrasenya mentre la teclejeu."

#. Type: password
#. Description
#: ../passwd.templates:17
msgid ""
"Please enter the same root password again to verify that you have typed it "
"correctly."
msgstr ""
"Si us plau introduïu la mateixa contrasenya de root un altre cop per a "
"verificar que l'heu teclejada correctament."

#. Type: boolean
#. Description
#: ../passwd.templates:24
msgid "Create a normal user account now?"
msgstr "Voleu crear ara un compte d'usuari normal?"

#. Type: boolean
#. Description
#: ../passwd.templates:24
msgid ""
"It's a bad idea to use the root account for normal day-to-day activities, "
"such as the reading of electronic mail, because even a small mistake can "
"result in disaster. You should create a normal user account to use for those "
"day-to-day tasks."
msgstr ""
"És una mala idea usar el compte de root per a les activitas quotidianes, "
"tals com llegir el correu electrònic, perque tan sols una petita errada pot "
"resultar un desastre. Heu de crear un compte d'usuari que podreu usar per a "
"aquestes tasques quotidianes."

#. Type: boolean
#. Description
#: ../passwd.templates:24
msgid ""
"Note that you may create it later (as well as any additional account) by "
"typing 'adduser ' as root, where  is an user name, like "
"'imurdock' or 'rms'."
msgstr ""
"Tingueu en compte que podeu crear-lo després (de la mateixa manera que "
"qualsevol altre compte) teclejant «adduser » com a root, on "
" és quelcom semblant a «imurdock» o «rms»."

#. Type: string
#. Description
#: ../passwd.templates:36
msgid "Full name for the new user:"
msgstr "Nom complet pel nou usuari:"

#. Type: string
#. Description
#: ../passwd.templates:36
msgid ""
"A user account will be created for you to use instead of the root account "
"for non-administrative activities."
msgstr ""
"Es crearà un compte d'usuari per a ser usat en comptes del compte de «root» 
"
"per a tasques no administratives."

#. Type: string
#. Description
#: ../passwd.templates:36
msgid ""
"Please enter the real name of this user. This information will be used fo

Bug#314668: O: posixtestsuite

[Guillem Jover]

Hi Kurt,

On Fri, Jun 24, 2005 at 08:52:14PM +0200, Kurt Roeckx wrote:
> Are you interested in taking over posixtestsuite?  If you're not,
> I might take it.

We were going to adopt it under the wings of the GNU/k*BSD team,
if you are interested in co-maint with us, I suppose that would
be fine.

I've not yet uploaded anything because I wanted to get rid of cdbs,
but I suppose I'll end up just adopting and then changing stuff
afterwards.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318366: FTBFS: Patch not found

[Guillem Jover]

Hi,

I'm just CCing Matthias Klose because I'm unsure if this is a problem
in gcc-4.0.

On Thu, Jul 14, 2005 at 03:29:25PM -0700, Matt Kraai wrote:
> Package: arj
> Version: 3.10.21-4
> Severity: serious
> 
> arj fails to build from source with the following error message:
> 
> > ./linux-gnu/en/rs/tools/postproc linux-gnu/en/rs/arj/arj
> > POSTPROC v 1.30  [17/01/2003]  Not a part of any binary package!
> > 
> > Patch not found

I fixed this problem for gcc-3.4, by changing an unreferenced variable
to a "static const", this worked even with -O2 at the time. With gcc-4.0
it's removing the variable, but reading the documentation there it's
stated that -fkeep-static-consts is used by default, and even if
explicitely specified it keeps removing the variable. I talked with
Matthias and he suggested to add a reference to that variable from an
existing function, but I'm curious to know if this is a problem in the
compiler itself.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#300080: inetutils: FTBFS (amd64/gcc-4.0): array type has incomplete element type

[Guillem Jover]

Hi,

On Thu, Mar 17, 2005 at 04:04:51PM +0100, Andreas Jochens wrote:
> Package: inetutils
> Severity: normal
> Tags: patch
> 
> When building 'inetutils' on amd64 with gcc-4.0,
> I get the following error:

Sorry for the delay, somehow the mainteinance of inetutils sliped from
our hands. I'll be uploading a fixed package tomorrow or so.

And thanks for the patch!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#186873: ppmd: reopen non-fixed bugs

[Guillem Jover]

package ppmd
found 178840 9.1-12
found 186873 9.1-12
thanks

Those bugs are not fixed with the latest upload. Alpha and IA64 still
have runtime problems.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#291939: [ARCH] Add support for Architecture aliases/wildcards

[Guillem Jover]

tags 291939 patch
retitle 291939 [ARCH] Add support for Architecture aliases/wildcards
thanks

Hi Scott,

I've finally had the time to finish this patch. I've polished the
initial version I showed you at Debconf, moved the read_{cpu,os}table
functions to controllib.pl, thus eliminating the need to expand the
arches externally through dpkg-architecture.

Those aliases will only affect the debian/control file, so will not
change the debian source (.dsc, .changes) or binary format (.deb).
Once the new dpkg source format is introduced the source format
could use the new aliases instead.

The new aliases are:

  -any
  linux-
  any-
  any-any
  all-all

I've not added "all-any" and "any-all" because they do not make
sense right now, but maybe would be nice to have, just for
consistency.

I've added two new commands to dpkg-architecture so other programs
can use the same logic w/o having to reimplement it, also that will
allow adding aliases there and everyone will benefit automagically.
Those are -e for equality (eq) and -i for
identity (is). The only problem is that when you set the current
arch with -a it spews a warning, so it's a bit annoying (maybe that
could be removed?).

So you can ask things like:

  - "current arch" eq i386?
dpkg-architecture -ei386 && echo yes
  - alpha eq linux-alpha?
dpkg-architecture -aalpha -elinux-alpha 2>/dev/null && echo yes
  - "current arch" is any-sparc?
dpkg-architecture -iany-sparc && echo yes
  - alpha is linux-any?
dpkg-architecture -aalpha -ilinux-any 2>/dev/null && echo yes
  - kfreebsd-i386 is any-i386?
dpkg-architecture -akfreebsd-i386 -iany-i386 2>/dev/null && echo yes

Once this patch is accepted, bug #112325 can be closed as well as
it can be handled with the new wildcards.

Patch attached, apply, rename "scripts/controllib.pl" to
"scripts/controllib.pl.in" and autoreconf. I've included as well two
hackish source packages to test the new stuff, the test-source is for
dpkg-checkbuilddeps and dpkg-source and test-binary for the remaning
stuff, just debuild and check.

regards,
guillem
diff -aur dpkg-1.13.10.orig/scripts/controllib.pl 
dpkg-1.13.10/scripts/controllib.pl
--- dpkg-1.13.10.orig/scripts/controllib.pl 2005-06-06 07:07:12.0 
+0300
+++ dpkg-1.13.10/scripts/controllib.pl  2005-07-23 23:52:17.0 +0300
@@ -12,6 +12,8 @@
 # "S key" where S is the source and key is the packagename
 # %substvar - map with substitution variables
 
+$pkgdatadir=".";
+
 $parsechangelog= 'dpkg-parsechangelog';
 
 grep($capit{lc $_}=$_, qw(Pre-Depends Standards-Version Installed-Size
@@ -80,6 +82,114 @@
 $substvar{'Arch'}= $arch;
 }
 
+sub read_cputable {
+open CPUTABLE, "$pkgdatadir/cputable"
+   or &syserr("unable to open cputable");
+while () {
+   if (m/^(?!\#)(\S+)\s+(\S+)\s+(\S+)/) {
+   $cputable{$1} = $2;
+   $cputable_re{$1} = $3;
+   push @cpu, $1;
+   }
+}
+close CPUTABLE;
+}
+
+sub read_ostable {
+open OSTABLE, "$pkgdatadir/ostable"
+   or &syserr("unable to open ostable");
+while () {
+   if (m/^(?!\#)(\S+)\s+(\S+)\s+(\S+)/) {
+   $ostable{$1} = $2;
+   $ostable_re{$1} = $3;
+   push @os, $1;
+   }
+}
+close OSTABLE;
+}
+
+sub debian_arch_fix
+{
+local ($os, $cpu) = @_;
+
+if ($os eq "linux") {
+   return $cpu;
+} else {
+   return "$os-$cpu";
+}
+}
+
+sub debian_arch_split {
+local ($_) = @_;
+
+if (/^([^-]*)-(.*)/) {
+   return ($1, $2);
+} elsif (/any/ || /all/) {
+   return ($_, $_);
+} else {
+   return ("linux", $_);
+}
+}
+
+sub debian_arch_eq {
+my ($a, $b) = @_;
+my ($a_os, $a_cpu) = debian_arch_split($a);
+my ($b_os, $b_cpu) = debian_arch_split($b);
+
+return ("$a_os-$a_cpu" eq "$b_os-$b_cpu");
+}
+
+sub debian_arch_is {
+my ($real, $alias) = @_;
+my ($real_os, $real_cpu) = debian_arch_split($real);
+my ($alias_os, $alias_cpu) = debian_arch_split($alias);
+
+if ("$real_os-$real_cpu" eq "$alias_os-$alias_cpu") {
+   return 1;
+} elsif ("$alias_os-$alias_cpu" eq "any-any") {
+   return 1;
+} elsif ("$alias_os-$alias_cpu" eq "any-$real_cpu") {
+   return 1;
+} elsif ("$alias_os-$alias_cpu" eq "$real_os-any") {
+   return 1;
+}
+
+return 0;
+}
+
+&read_cputable;
+&read_ostable;
+
+sub debian_arch_expand
+{
+local ($_) = @_;
+
+/^(!)?(.*)/;
+
+local $not = $1;
+local $arch = $2;
+local ($os, $cpu) = debian_arch_split($arch);
+local @list;
+
+if ("$os-$cpu" eq 'any-any') {
+   @list = 'any';
+} elsif ($os eq 'all' or $cpu eq 'all') {
+   @list = 'all';
+} elsif ($cpu eq 'any') {
+   foreach my $_cpu (@cpu) {
+   push @list, $not.debian_arch_fix($os, $_cpu);
+   }
+} elsif ($os eq 'any') {
+   foreach my $_os (@os) {
+   push @list, $not.debian_arch_fix($_os, $cpu);
+   }
+} else {
+   pu

Bug#280987: Don't the testing scripts already do that?

[Guillem Jover]

Hi,

On Fri, Jul 15, 2005 at 09:21:40AM -0400, Anthony DeRobertis wrote:
> Don't the testing scripts already keep it out due to the gnumach bugs,
> without needing to file this fake bug?
> 
> At least reading:
> http://bjorn.haxx.se/debian/testing.pl?package=gnumach
> seems to indicated they will.

The only link with gnumach is a Build-Depends and that was not
tracked by britney at the time of filing this bug, I'm not sure
if it does now, I think it does not but I'll check once ftp-master
is up again.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#301146: util-linux: fdisk: bad debian patch

[Guillem Jover]

Hi Andries,

I should have contacted you about the porting patch I did long time
ago, sorry about that. I'll be resyncronizing it again as it has been
removed from the Debian package due to much divergence with upstream,
and will send it straight to you.

On Thu, Mar 24, 2005 at 01:24:19AM +0100, [EMAIL PROTECTED] wrote:
> Package: util-linux
> Version: 2.12-10
> 
> On Debian 3.1 on a system with 64-bit kernel and 32-bit user space
> fdisk as distributed by Debian gives the kernel error message
> 
> Mar 23 19:38:56 localhost kernel: ioctl32(fdisk:4588): Unknown cmd fd(4) 
> cmd(40081272){00} arg(7fff7bf8) on /dev/sda
> 
> The vanilla upstream package works fine.
> This Debian bug is caused by the patch by Guillem Jover: it has
> 
> #define BLKGETSIZE64 _IOR(0x12,114,long long)

Hmmm I couldn't recall doing that in my initial patch, I only moved
the ioctl definitions into a single place without touching them,
I've tracked it to a change made in <http://bugs.debian.org/218894>.

> but that is the wrong definition - the last argument should be size_t.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#240587: acknowledged by developer (Experimental upload now in unstable)

[Guillem Jover]

Hey Martin,

On Thu, Mar 24, 2005 at 03:04:25AM -0800, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #240587: ITP: ufsutils -- utilities for the UFS filesystem,
> which was filed against the wnpp package.
> 
> It has been closed by one of the developers, namely
> Martin Michlmayr <[EMAIL PROTECTED]>.

> >From [EMAIL PROTECTED] Thu Mar 24 02:56:01 2005
> Return-path: <[EMAIL PROTECTED]>
> Date: Thu, 24 Mar 2005 03:56:00 -0700
> From: Martin Michlmayr <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Experimental upload now in unstable
> Message-ID: <[EMAIL PROTECTED]>
> Sender: Martin Michlmayr <[EMAIL PROTECTED]>
> 
> This WNPP bug was tagged "fixed-in-experimental", but the package has
> since then moved to unstable.

Hmmm when did that happen? :)

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#240587: acknowledged by developer (Experimental upload now in unstable)

[Guillem Jover]

On Fri, Mar 25, 2005 at 07:57:52AM +, Martin Michlmayr wrote:
> * Guillem Jover <[EMAIL PROTECTED]> [2005-03-25 03:48]:
> > > This WNPP bug was tagged "fixed-in-experimental", but the package has
> > > since then moved to unstable.
> > 
> > Hmmm when did that happen? :)
> 
> It didn't... the package is still only in experimental.  I've fixed my
> script already.
> 
> I think the bug should be closed anyway since the package is in the
> archive but if you disagree please feel free to re-open it.

I don't disagree, it's just that the reason was bogus. =P
Closing this bug was on my todo list anyway. So thank! :)

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#298197: /etc/init.d/gpm start needs to be called twice

[Guillem Jover]

Hi,

On Sat, Mar 05, 2005 at 05:54:49PM +0100, Helge Kreutzmann wrote:
> Package: gpm
> Version: 1.19.6-19
> Severity: important
> 
> Calling /etc/init.d/gpm start once only causes messages to be printed,
> but gpm does not work. Only after /etc/init.d/gpm start is called a
> second time, gpm works.

> Here is the transscript:
> remaxp:/scr/media/ToDisk/01/numerik-div# /etc/init.d/gpm start
> Starting mouse interface server: gpm.
> remaxp:/scr/media/ToDisk/01/numerik-div#
> input: ImExPS/2 Logitech Explorer Mouse on isa0060/serio1
> mice: PS/2 mouse device common for all mice
> ts: Compaq touchscreen protocol output
> remaxp:/scr/media/ToDisk/01/numerik-div# /etc/init.d/gpm start
> Starting mouse interface server: gpm.
> 
> As you can see, after the first call some messages are printed (ImExPS/2 ...)
> they come with some delay, i.e., if the first call is happening in an init
> script, then they are usually printed after the next service (e.g., xfs).
> 
> The second time these messages are not printed and only then gpm 
> works. 
> 
> I think that the messages come from some modules, and that gpm maybe needs
> to wait after loading them?

Yes they come from the modules loeaded, but gpm does not load them, at
least directly, they get loaded because the kernel sees someone is
requesting such functionality and after that loads them, I think we
have a similar bug report, and the problem was solved by addig a delay
in gpm, I'm not sure about this solution tough...

We'll think on a clean way to solve this.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#317008: pistachio-doc: Wrong license for the reference manual

[Guillem Jover]

Hi Uwe,

On Tue, Jul 05, 2005 at 04:06:47PM +0200, Uwe Dannowski wrote:
> Package: pistachio-doc
> Version: 0.4+20041228-4
> Severity: minor
> 
> The license in /usr/share/doc/pistachio-doc/copyright does not apply to the
> reference manual in /usr/share/doc/pistachio-doc/refman . The appropriate
> license can be found on page ii in the reference manual.

Thanks for pointing this out. I'll remove the refman from next release
as it does not comply with the DFSG. Also I'll have to remove the
white-paper as it does not have sources available, or are they
somewhere?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#317430: ITP: apt-history -- logs the changes when installing

[Guillem Jover]

Hi,

On Fri, Jul 08, 2005 at 02:03:32PM +0200, Nico Golde wrote:
> * Package name: apt-history
>   Version : 0.1
>   Upstream Author : Vittorio Palmisano <[EMAIL PROTECTED]>
> * URL : http://redclay.altervista.org/archivio/python/apt-history/
> * License : GPL
>   Description : logs the changes when installing
> 
> apt-history logs the changes of /var/lib/dpkg/status when installing,
> removing, upgrading packages with apt-get

Does this package makes sense now that dpkg logs into
/var/log/dpkg.log?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#303488: ITP: openhackware -- OpenFirmware emulator

[Guillem Jover]

Package: wnpp
Severity: wishlist
Owner: Guillem Jover <[EMAIL PROTECTED]>

* Package name: openhackware
  Version : 0.4
  Upstream Author : Jocelyn Mayer <[EMAIL PROTECTED]>
* URL : <http://perso.magic.fr/l_indien/OpenHackWare/>
* License : GPL
  Description : OpenFirmware emulator

 OpenHackWare is an OpenFirmware emulator intended to be used on PowerPC
 machines. It is not a real OpenFirmware as it knows nothing about Forth.
 It emulates the OpenFirmare boot time interface as well as the RTAS
 interface. It also emulates some known "interpret" strings, to make it
 able to launch known OSes.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#303489: ITP: proll -- JavaStation PROM 2.x compatible replacement

[Guillem Jover]

Package: wnpp
Owner: Guillem Jover <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: proll
  Version : 18
  Upstream Author : Pete A. Zaitcev <[EMAIL PROTECTED]>
* URL : <http://people.redhat.com/zaitcev/linux/>
* License : GPL
  Description : JavaStation PROM 2.x compatible replacement

 Proll is a 2.x PROM compatible replacement for JavaStations, that can
 be used on emulators such as Qemu or to make possible booting Linux, as
 later 3.x series of the PROMs are unable to boot it.
 .
 JavaStations came with two different PROMs installed in them. Version 2.30
 shipped with the earliest Mr. Coffee models, and was updated by latter
 versions of the Sun Netra J software environment to 3.11. Krups and
 Espresso came with 3.x versions of the PROM by default.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332598: unace as alternative

[Guillem Jover]

Hi,

On Thu, Oct 13, 2005 at 01:02:59PM +0200, Fabian Greffrath wrote:
> Am Samstag, den 08.10.2005, 16:34 +0300 schrieb Guillem Jover:
> > With this do you mean coexist with another debian package with the
> > same name, but greater version?
> 
> I guess it would be hardly possible for two different packages with the
> same name to coexist on a Debian system...?!

Well it's not possible, that's why I was asking. =)

> The unace-package will be called something like unace2-binary and it
> will provide the files /usr/bin/unace and /usr/man/man1/unace.1 (which
> will be your manpage revised for unace version 2.xx) among others.
> Because we do not want our package to conflict with the free unace in
> Debian (your package), but coexist, both of us need to use the
> alternatives system for the forementioned files.

Well if you are providing a package with different name but same
binaries I'd suggest renaming the binaries. Another option would be
to dpkg-divert.

But I'd really prefer not having to touch the unace package, and you
making an unace named package with version 2.20-0, and keep at 0 so
if someday it gets released as free software it can be uploaded in
debian and will be upgraded correctly. I think that's the most logical
option with less overhead on packaging.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321232: qemu: New upstream version available

[Guillem Jover]

Hi Stephen,

On Wed, Sep 28, 2005 at 01:22:56PM +0200, Stephen Kitt wrote:
> Package: qemu
> Version: 0.7.2-0.1
> Tags: patch
> Followup-For: Bug #321232

> QEMU 0.7.2 has been available for a while. I've rebased most of the
> Debian package's patches against the new version; I'm attaching the
> resulting .diff.gz.

Yes we know, and thanks for your work, we'll use that when preparing
the new package. I'd like to have a buildable video.x driver, and make
qemu build on kfreebsd-i386 before uploading.

> The only missing patch is 50_ppc_ldscript.patch;
> the upstream ppc.ld has changed and I can't check the patch.

I'll take a look on this.

> I've also included kqemu.h and enabled kqemu support
> (45_kqemu.patch), but I haven't changed the debian/copyright file
> to include its license.

I'll take a look on this as well, maybe we'll use the qvm86 header
file instead.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#318752: intent to NMU

[Guillem Jover]

Hi Dann,

On Wed, Sep 07, 2005 at 07:43:46PM -0600, dann frazier wrote:
> Since this bug has been open for 52 days with a patch, I intend to NMU
> it in 1 week (or sooner, at the maintainer's request).

First of all, thanks for the patch and sorry for not replying. I've
been on holidays the past few weeks. And I'm currently wading through
the usual backlog. One of the updates I wanted to do was inetutils. If
you see I've not done so in a week or so, please go ahead and NMU.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#314976: directvnc: current package is uninstallable

[Guillem Jover]

package directvnc
severity 314976 serious
thanks

Hi Ola,

This package cannot be installed in unstable due to the missing
libdirectfb-0.9-20 package in the archive. Please rebuild with
the latest directfb version.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#327622: FTBFS on GNU/kFreeBSD

[Guillem Jover]

Hi,

On Sun, Sep 11, 2005 at 05:09:50PM +0200, Robert Millan wrote:
> Package: qemu
> Version: 0.7.0-4+kbsd
> Severity: important
> Tags: patch
> 
> Attached is a patch to build qemu on GNU/kFreeBSD. It requires to
> update the package to 0.7.2 source first.

No problem, that was in the plan already. :>

I've skimmed over it, I'll check for its correctness this week or so.
Thanks for dealing with this. ;)

> Please take the following considerations (from patch header):
> 
>   Don't send to upstream.  This patch conflicts with the one in the FreeBSD 
> ports
>   collection, where sane replacements for some of these hunks are being 
> merged.
> 
>   Don't modify this patch directly.  It is generated semi-automaticaly from 
> the
>   stuff in http://glibc-bsd.alioth.debian.org/patches/qemu/.  When updating 
> for a
>   new qemu release, it should be generated the same way.

Do you know if the FreeBSD maintainer is going to send those patches?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#328028: laptop-mode-tools: Invokes hdparm unconditionally

[Guillem Jover]

Package: laptop-mode-tools
Version: 1.10-1

Hi,

This packages recommends hdparm, and on my laptop it's not installed,
but then laptop_mode does not check if it's available, and thus I get
a hude amount of lines with errors trying to exec it.

Please make the invokation of hdparm only if it's available. Or a less
desirable solution would be to move it from a Recommends to a Depends.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322344: Use qvm86 instead

[Guillem Jover]

Hi Paul,

On Tue, Sep 13, 2005 at 05:53:02PM +0100, Paul Brook wrote:
> qvm86 support would be more appropriate. qvm86 is a GPL replacement 
> for kqemu.
> 
> http://www.qvm86.org/

Do not worry I didn't have any intention to support the non-free
one (I think I can speak in name of the other maintainers as well). =P

We have just been waiting a bit for it to be more mature.

And thanks for writting this piece of source!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332598: unace as alternative

[Guillem Jover]

Hi,

On Fri, Oct 07, 2005 at 10:57:31AM +0200, Fabian Greffrath wrote:
> package: unace
> severity: wishlist
> 
> Please consider handling the unace binary as 'alternatives',
> allowing it to coexist with proprietary versions (=2.20) of unace,
> which can be downloaded from unofficial repositories.

With this do you mean coexist with another debian package with the
same name, but greater version?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#333213: libflash-mozplugin: Adds '/usr/lib' to /etc/ld.so.conf

[Guillem Jover]

Package: libflash-mozplugin
Version: 0.4.13-4
Severity: serious

Hi,

This package is breaking builds with libncurses5-dev, at least.
Those builds are unable to resolve from which packages does
/usr/lib/libncurses.so.5 come from as it is an unowned symlink.
This is due to the libflash-mozplugin.postinst adding '/usr/lib'
to '/etc/ld.so.conf', for no reason.

Please stop doing this. (And once you've removed the add and removal
logic you'll get a redundant ldconfig call, so you can completely
remove libflash-mozplugin postinst and postrm).

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#326644: gpm: modifies conffile?

[Guillem Jover]

package gpm
tag 326644 wontfix sarge
retitle 326644 gpm: ucf considers non-ucf config file manually modified
thanks

Hi,

On Tue, Sep 06, 2005 at 11:56:23AM -0400, Justin Pryzby wrote:
> # Severity change pending a mutual agreement of the problem.
> reopen 326644
> thanks

> On Tue, Sep 06, 2005 at 06:32:12AM +0300, Guillem Jover wrote:
> > On Sun, Sep 04, 2005 at 02:13:24PM -0400, Justin Pryzby wrote:
> > > Package: gpm
> > > Severity: serious
> > > Version: 1.19.6-21
> > > File: /etc/gpm.conf
> > > Justification: maintscripts apparently modify conffile (violates: 10.7.3)
> > 
> > That's wrong. This file is a configuration file, and not a conffile.

> Okay, but the effect is the same.  The intent of policy is that
> upgrades prompt the user iff:
> 
>  - the conffile is modified by the maintainer (a different version is
>shipped in a newer version of a package than in an older version,
>causing the md5sum to change); AND
> 
>  - the conffile which was installed by a previous version of the
>package being upgraded was locally modified by the administrator.

s/conffile/configuration file/.

> If either of the above are false, then no prompting is necessary, and
> the upgrade can non-interactively do the expected thing.
> 
> Is it true that /etc/gpm.conf used to be a conffile?  I don't
> understand any other way that I could be prompted.

No, it has not been a conffile ever. It was a configuration file
on woody and it is on sarge through sid.

> Agree, that a transition to debconf+ucf could be nontrivial.

It only transitioned from being generated with a script (gpmconfig)
to be handled with ucf+debconf, and that happened on sarge. The
transition was pretty easy.

> > Well, even if annoying, we cannot do anything about that, because
> > that's due to the transition to debconf + ucf, and we cannot fix and
> > get that into sarge anyway. So I'm closing this bug, if you disagree,
> > please reopen and lower the severity to normal or similar.

(See at the end).

> A solution exists for any technical problem.
>
> Have you seen:
> 
>   http://www.dpkg.org/ConffileHandling

That does not help. As I've said several times it has not been a
conffile ever.

> > Although that will be pointless as that will not happen anymore on
> > sarge -> etch upgrade, and Debian only supports upgrading from one
> > release to the next one.

> Huh?  I upgraded to the GPM that migrated to testing ~2 days ago.  So
> right now it is a "candidate" version for inclusion into etch; if you
> don't release any new version, then this GPM will probably be the one
> in etch.

> What I would like to see is a GPM update which properly handles this
> UCF transition uploaded to unstable, as the new etch "candidate".
> Although _I_ will never see the conffile prompt again, everyone else
> who updates from a sarge gpm to any ucf-enabled gpm will get the
> prompt, which is something to be avoided.  It is an especially big
> problem during dist-upgrades, when many packages have similar
> problems.  Users shouldn't need to spend massive amounts of time
> reading diffs only to discover that they are being unnecessarily
> prompted.

The version in sarge is 1.19.6-19sarge1, the one you upgraded from was
1.19.6-20. The one now on etch and sid is 1.19.6-21. Debconf support
got introduced in version 1.19.6-14, ucf support got introduced in
1.19.6-15.

The problem here is that we didn't forcibly add the md5sum of the
previous non-ucf file to the ucf database. So it was marked as
modified, then you didn't install any new config file version handled
by ucf, so it kept thinking it was manually generated. And now is too
late to fix that as that needed to be done on the upgrade from woody
to sarge, which we cannot fix anymore (as I've said earlier). So users
have had to deal with this. And once an ucf version is installed we
cannot distinguish between a modified version and a previous non-ucf
file.

Marking this bug wontfix, but I don't really see the point in keeping
this open, and I think that RC is an exaggeration on the magnitude of
the problem. Peter?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#322300: openhackware: should not try to build on !powerpc environments

[Guillem Jover]

package openhackware
severity 322300 normal
retitle 322300 openhackware: should not try to build on !powerpc environments
thanks

On Wed, Aug 10, 2005 at 09:22:17AM +0200, Reinhard Tartler wrote:
> Package: openhackware
> Version: 0.4.1-1
> Severity: Serious

> I tried to build openhackware on i386 (well, actually on amd64 inside a
> chroot), but did not succeed. I attached the build log.

Yes, it does not build because as Peter explained it's ppc specific
code, and needs a ppc build environment.

On Wed, Aug 10, 2005, Peter 'p2' De Schrijver wrote:
> This package only works on ppc as it contains ppc assembler code. The
> architecture field in debian/control should therefor be
>
> Architecture: powerpc

No, it's code that can be used by emulators like qemu, that's why
it's an all package, there's existing practice for this, and the
problem comes from a deficiency in the source format, that does
not allow to specify that an all package needs a specific building
environment (or arch).

The only thing I can do is fail gracefully with a message if the
environment, be it native or a cross toolchain, is not the
apropropriate.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#323102: xfstt: FTBFS: Missing Build-Depends on 'libxt-dev, xlibs-static-dev'

[Guillem Jover]

package xfstt
tags 323102 - patch
thanks

On Sun, Aug 14, 2005 at 08:23:33PM +0200, Andreas Jochens wrote:
> Package: xfstt
> Version: 1.6-5
> Severity: serious
> Tags: patch

> When building 'xfstt' in a clean 'unstable' chroot,
> I get the following error:

> make[3]: Entering directory `/xfstt-1.6/src'
> if g++ -DHAVE_CONFIG_H -I. -I. -I..  -DLOCALEDIR=\""/usr/share/locale\"" 
> -DFONTDIR=\""/usr/share/fonts/truetype\"" -DCACHEDIR=\""/var/cache/xfstt\"" 
> -DPIDFILE=\""/var/run/xfstt.pid\"" -DMAGNIFY=0 -I../libfstt   -Wall -g -O2 
> -fomit-frame-pointer -ffast-math -MT xfstt-xfstt.o -MD -MP -MF 
> ".deps/xfstt-xfstt.Tpo" \
>   -c -o xfstt-xfstt.o `test -f 'xfstt.cc' || echo './'`xfstt.cc; \
> then mv -f ".deps/xfstt-xfstt.Tpo" ".deps/xfstt-xfstt.Po"; \
> else rm -f ".deps/xfstt-xfstt.Tpo"; exit 1; \
> fi
> xfstt.cc:69:26: error: X11/fonts/FS.h: No such file or directory
> xfstt.cc:70:31: error: X11/fonts/FSproto.h: No such file or directory
> 
> Please add the missing Build-Depends on 'libxt-dev, xlibs-static-dev'
> to debian/control.

No, this fails to build, but the problem is not in xfstt but in
libfs-dev, there's a bug report there pending upload (321641). I'll keep
this open so other people do not submit it again, and will close once
libfs-dev is uploaded.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#320382: lintian: wrong warning on statically linked binaries under /boot

[Guillem Jover]

Package: lintian
Version: 1.23.10
Tags: patch

Hi,

The package pistachio installs some elf statically linked files under
/boot/l4/ and lintian spews a warning about that. Attached a patch to
correct this.

regards,
guillem
diff -Naur lintian-1.23.10/checks/binaries lintian-1.23.10.new/checks/binaries
--- lintian-1.23.10/checks/binaries 2005-07-10 18:05:31.0 +0300
+++ lintian-1.23.10.new/checks/binaries 2005-07-29 01:48:19.0 +0300
@@ -180,8 +180,7 @@
} else {
# Some exceptions: files in /boot, /usr/lib/debug/*, named *-static 
or
# *.static, or *-static as package-name.
-   use File::Basename;
-   next if (dirname($file) eq './boot');
+   next if ($file =~ m#^./boot/#);
# Location of debugging symbols:
next if ($file =~ m#^./usr/lib/debug/#);
next if ($file =~ /(\.|-)static$/);

Bug#321019: qemu: FTBFS: Architecture: 1 in .dsc file.

[Guillem Jover]

Hi,

On Tue, Aug 02, 2005 at 11:11:12PM +0200, Kurt Roeckx wrote:
> Package: qemu
> Version: 0.7.0-3
> Severity: serious

> The package is failing to build on all arches.  The reason is
> that the .dsc file says:

> Architecture: 1

> While that last line should say:
> Architecture: amd64 i386 powerpc alpha sparc arm s390

> If I just let it generate a source package again, it seems to
> work without any problems.

Argh, that was caused by a modified dpkg-dev supporting arch aliaeses
that I had locally installed, I've fixed it now and it should generate
the proper .dsc file. I just saw the all those build failures but didn't
have time to investigate the problem. Thanks for reporting!

> PS: Is there a reason for the arch restriction on
> build-dependency for libgpmg1-dev?  It's the same list as the one
> you're building for.

Yes, gpm is linux specific and the package can be build easily on
other non-linux ports, although I should be explicitely listing them.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#315374: dbs: please reorder find opts

[Guillem Jover]

package dbs
tags 315374 patch
thanks

Hi,

I'm including a patch for this, yo can find it attached.

regards,
guillem
diff -Naur dbs-0.35/dbs-edit-patch dbs-0.35.new/dbs-edit-patch
--- dbs-0.35/dbs-edit-patch 2004-05-14 01:14:23.0 +0300
+++ dbs-0.35.new/dbs-edit-patch 2005-07-30 18:24:14.0 +0300
@@ -129,7 +129,7 @@
 fi
   
 # EXTRACT SOURCE FILES
-for f in `find $SRC_TAR_DIR -type f -maxdepth 1 -name \*.tgz -o -name 
\*.tar.gz -o -name \*.tar.bz -o -name \*.tar.bz2 | LC_COLLATE=C sort`; do 
+for f in `find $SRC_TAR_DIR -maxdepth 1 -type f -name \*.tgz -o -name 
\*.tar.gz -o -name \*.tar.bz -o -name \*.tar.bz2 | LC_COLLATE=C sort`; do 
 file=`basename $f`
 echo -n "Extracting source $file ... "; 
 if "$FILE2CAT" "$f" | tar -C $OUT_DIR -xvf - > /dev/null; then 
@@ -143,7 +143,7 @@
 case "$STRIP" in
   1)
 # DETERMINE DIRECTORY NAME (assume only one exists)
-for f in `find $OUT_DIR -type d -maxdepth 1`; do 
+for f in `find $OUT_DIR -maxdepth 1 -type d`; do 
   DEST_DIR="$f"
 done
 ;;
@@ -211,7 +211,7 @@
 : > new_patch
 EOF
 
-for f in `find "$OUT_DIR" -type d -mindepth 1 -maxdepth 1`; do 
+for f in `find "$OUT_DIR" -mindepth 1 -maxdepth 1 -type d`; do 
   file=`basename "$f"`
   echo -n "Copying $file to $file-old ... "; 
   cp -a "$f" "$f-old"

Bug#291939: [ARCH] Add support for Architecture aliases/wildcards

[Guillem Jover]

Hi,

I've been using dpkg debs with this patch for some time and the only
problem until now has been a stupid error left when I switched from
expanding the aliases via dpkg-architecture to an internal function.
The function was returning a list and split was expecting a scalar.

Fixed in this incremental patch, and included as well initial updated
text for the man page, although this should be reviewed by a native
English speaker. :)

To test that the new patch fixes the problem, "dpkg-source -b" can be
tried with qemu or pistachio, otherwise they'll produce a .dsc file
with an "Architecture: 1" field.

regards,
guillem
diff -Naur man/C/dpkg-architecture.1 man/C/dpkg-architecture.1
--- man/C/dpkg-architecture.1   2005-06-14 16:17:18.0 +0300
+++ man/C/dpkg-architecture.1   2005-08-03 06:02:40.0 +0300
@@ -11,8 +11,8 @@
 \&\fB\-f\fR
 .PP
 Valid actions:
-\&\fB\-l\fR, \fB\-q\fRVariable\-Name, \fB\-s\fR, \fB\-u\fR, \fB\-c\fR Command,
-\fB\-L\fR
+\&\fB\-l\fR, \fB\-e\fRDebian\-Architecture, \fB\-i\fRArchitecture\-Alias,
+\fB\-q\fRVariable\-Name, \fB\-s\fR, \fB\-u\fR, \fB\-c\fR Command, \fB\-L\fR
 .SH "DESCRIPTION"
 .IX Header "DESCRIPTION"
 dpkg-architecture does provide a facility to determine and set the build and
@@ -30,8 +30,12 @@
 will warn you if your choice doesn't match the default.
 .PP
 The default action is \fB\-l\fR, which prints the environment variables, one 
each line,
-in the format VARIABLE=value. If you are only interested in the value of a
-single variable, you can use \fB\-q\fR. If you specify \fB\-s\fR, it will 
output an export
+in the format VARIABLE=value. If you want to check for equality between two
+Debian Architectures, you can use \fB\-e\fR, by default it will compare against
+the currect Denian Architecture, being it the host. If you want to check for
+identity of the current Debian Architecture against an Architecture Alias, you
+can use \fB\-i\fR. If you are only interested in the value of a single 
variable,
+you can use \fB\-q\fR. If you specify \fB\-s\fR, it will output an export
 command. This can be used to set the environment variables using eval. 
\fB\-u\fR
 does return a similar command to unset all variables. \fB\-c\fR does execute a
 command in an environment which has all variables set to the determined
@@ -55,6 +59,11 @@
 .IX Item "Debian Architecture"
 The Debian archietcture string, which specifies the binary tree in the 
\s-1FTP\s0
 archive. Examples: i386, sparc, hurd\-i386.
+.IP "Architecture Alias" 4
+.IX Item "Architecture Alias"
+An architecture alias is a wildcard architecture that will match any real
+architecture being part of it. The general form is \-.
+Examples: linux\-any, linux\-alpha, any\-i386, hurd\-any.
 .IP "\s-1GNU\s0 System Type" 4
 .IX Item "GNU System Type"
 An architecture specification string consisting of two parts,
diff -Naur scripts/dpkg-source.pl scripts/dpkg-source.pl
--- scripts/dpkg-source.pl  2005-08-03 04:39:30.0 +0300
+++ scripts/dpkg-source.pl  2005-08-03 04:37:09.0 +0300
@@ -173,7 +173,7 @@
if (grep($sourcearch[0] eq $_, 'any','all'))  {
@sourcearch= ('any');
} else {
-   my @arches = map(split(/\s+/, debian_arch_expand($_)),
+   my @arches = map(debian_arch_expand($_),
 split(/\s+/, $v));
chomp @arches;
for $a (@arches) {

Bug#321641: libfs-dev: Missing depends on packages providing needed header files

[Guillem Jover]

Package: libfs-dev
Version: 6.8.2.dfsg.1-4
Severity: serious

Some header files in this package include external headers from
other packages, but those are not listed in the Dependency field,
thus causing other packages to FTBFS.

  X11/fonts/FS.h:  #include 
  X11/fonts/FS.h:  #include 
  X11/fonts/FSlib.h:   #include 

  $ dpkg -S X11/fonts/fsmasks.h
  xlibs-static-dev: /usr/X11R6/include/X11/fonts/fsmasks.h
  $ dpkg -S X11/Xdefs.h
  x-dev: /usr/X11R6/include/X11/Xdefs.h
  $ dpkg -S X11/Xfuncproto.h
  x-dev: /usr/X11R6/include/X11/Xfuncproto.h

Please add the required packages (xlibs-static-dev and x-dev) in
the Depdency field, or if xlibs-static-dev is supposed to be phased
out, move the needed files (or just all files remaining under
"X11/fonts/") to libfs-dev.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321707: devscripts: wnpp-alert lists RFHs as RFAs

[Guillem Jover]

Package: devscripts
Version: 2.9.4
Tags: patch

Hi,

wnpp-list is listing RFHs as RFAs, the initial patch support in the
BTS had that correctly, I suppose it got mangled in the way to the
source. =)

Attached a really trivial patch that fixes this.

regards,
guillem
diff -Naur devscripts-2.9.4.orig/wnpp-alert.sh devscripts-2.9.4/wnpp-alert.sh
--- devscripts-2.9.4.orig/wnpp-alert.sh 2005-07-19 16:56:54.0 +0300
+++ devscripts-2.9.4/wnpp-alert.sh  2005-08-07 06:22:17.0 +0300
@@ -63,7 +63,7 @@
   sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/RFA \1 \2 -- \3/; T d; p; : d' >> $WNPP
 
 wget -q -O - http://www.debian.org/devel/wnpp/help_requested | \
-  sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/RFA \1 \2 -- \3/; T d; p; : d' >> $WNPP
+  sed -ne 's/.*\([^:<]*\)[: 
]*\([^<]*\)<\/a>.*/RFH \1 \2 -- \3/; T d; p; : d' >> $WNPP
 
 cut -f3 -d' ' $WNPP | sort > $WNPP_PACKAGES
 

Bug#403216: dpkg-shlibdeps: Fails to check /emul/ia32-linux/[usr/]lib

[Guillem Jover]

Hi,

On Mon, 2006-12-18 at 19:19:30 +0100, Aurelien Jarno wrote:
> Well this has been removed, and now the linker and the dynamic loader
> both know about /emul/ia32-linux/[usr/]lib, just as they now /lib64 and
> /usr/lib64 on 32-bit platforms.
> 
> I guess dpkg-shlibdeps have to know about those paths. Using
> /etc/ld.so.conf.d for that is messing bi-arch and multi-arch, which are
> different things.

After discussing this with Aurelien on IRC, I'll be adding the path to
dpkh-shlibdeps. This will be on next upload, which I'll target for few
days from now (after announcing in debian-dpkg).

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#407187: apt: use dpkg-architecture to get host architecture

[Guillem Jover]

Package: apt
Version: 0.6.46.4
Tags: patch

Hi,

As part of the move to armel, dpkg was patched (which should get the
patch merged upstream RSN), and apt needed patching as well to make it
aware of the new arch. This patch solves the problem by moving that
knowledge to dpkg where it belongs. This also avoids out of sync arch
support in the future between apt and dpkg.

Just for reference, the GNU triplet for armel is arm-linux-gnueabi, so
the patterns need to match on gnu%.

regards,
guillem
--- buildlib/archtable	2006-03-02 16:26:52.0 +0200
+++ buildlib/archtable	1970-01-01 02:00:00.0 +0200
@@ -1,29 +0,0 @@
-# This file contains a table of known architecture strings, with
-# things to map them to. `configure' will take the output of the
-# autoconf cannon macros and look in here. This only deals with architecture
-# (CPU) names.
-
-# The left side is a regex for awk
-
-i.86	i386
-pentium	i386
-sparc	sparc
-sparc64	sparc
-alpha.*	alpha
-m68k	m68k
-arm.*b	armeb
-arm.*	arm
-powerpc	powerpc
-ppc	powerpc
-powerpc64	ppc64
-mipsel  mipsel
-mipseb	mips
-mips	mips
-sheb	sheb
-shel	sh
-sh	sh
-hppa.*	hppa
-ia64	ia64
-s390	s390
-s390x	s390x
-x86_64	amd64
--- buildlib/environment.mak.in	2006-03-02 15:56:30.0 +0200
+++ buildlib/environment.mak.in	2006-12-14 23:31:21.0 +0200
@@ -62,7 +62,7 @@ NEED_SOCKLEN_T_DEFINE = @NEED_SOCKLEN_T_
 
 # Shared library things
 HOST_OS = @host_os@
-ifneq ($(words $(filter linux-gnu gnu% %gnu,$(HOST_OS))),0)
+ifneq ($(words $(filter gnu% linux-gnu% kfreebsd-gnu% %-gnu,$(HOST_OS))),0)
SONAME_MAGIC=-Wl,-soname -Wl,
LFLAGS_SO=
 else
--- buildlib/ostable	2006-03-02 15:46:44.0 +0200
+++ buildlib/ostable	1970-01-01 02:00:00.0 +0200
@@ -1,21 +0,0 @@
-# This file contains a table of known vendor-os strings, with
-# things to map them to. `configure' will take the output of the
-# autoconf cannon macros and look in here. This only deals with
-# OS names. The right should be a common name like the arch table
-# generates
-# The final bit to build the Debian Architecture is done in init.cc
-# The left side is a regex for awk, and the first match is used.
-
-# These are used by Debian
-[^-]*-linux-.*   linux
-[^-]*-kfreebsd.*-gnu   kfreebsd
-[^-]*-knetbsd.*-gnu   knetbsd
-[^-]*-gnu[^-]*   hurd
-
-# These are samples. 
-hp-hpux[^-]*	hp-ux
-sun-solaris[^-]*solaris
-[^-]*-openbsd[^-]*  openbsd
-
-# Catch all
-.*	unknown
--- configure.in	2006-10-30 09:51:28.0 +0200
+++ configure.in	2006-12-05 12:47:48.0 +0200
@@ -79,9 +79,9 @@ AC_SUBST(BDBLIB)
 dnl Converts the ARCH to be something singular for this general CPU family
 dnl This is often the dpkg architecture string.
 AC_MSG_CHECKING(system architecture)
-archset="`awk \" ! /^#|^\\\$/ { if(match(\\\"$target_cpu\\\",\\\"^\\\"\\\$1\\\"\\\$\\\")) {print \\\$2; exit}}\" $srcdir/buildlib/archtable`"
+archset="`dpkg-architecture -qDEB_HOST_ARCH`"
 if test "x$archset" = "x"; then
-  AC_MSG_ERROR(failed: use --host= or check buildlib/archtable)
+  AC_MSG_ERROR([failed: use --host= or output from dpkg-architecture])
 fi
 AC_MSG_RESULT($archset)
 AC_DEFINE_UNQUOTED(COMMON_CPU,"$archset")
@@ -89,7 +89,7 @@ AC_DEFINE_UNQUOTED(COMMON_CPU,"$archset"
 dnl Get a common name for the host OS - this is primarily only for HURD and is
 dnl non fatal if it fails
 AC_MSG_CHECKING(system OS)
-osset="`awk \" ! /^#|^\\\$/ {if (match(\\\"$target_vendor-$target_os\\\",\\\$1)) {print \\\$2; exit}}\" $srcdir/buildlib/ostable`"
+osset="`dpkg-architecture -qDEB_HOST_ARCH_OS`"
 AC_MSG_RESULT($osset)
 AC_DEFINE_UNQUOTED(COMMON_OS,"$osset")
 

Bug#407191: debianutils: armel and crosscompilation problems

[Guillem Jover]

Package: debianutils
Version: 2.17.4
Tags: patch

Hi,

While we were starting the armel port, I found that debianutils would
have problems when cross built, or when built for stuff with a
different ABI, like with the armel triplet arm-linux-gnueabi. Attached
is a patch that should solve this.

regards,
guillem
--- debian/rules	2006-12-02 22:56:07.0 +0200
+++ debian/rules	2007-01-16 20:56:53.0 +0200
@@ -10,7 +10,6 @@ INSTALL_SCRIPT  = $(INSTALL) -p-o ro
 INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
 
 DEB_BUILD_ARCH_OS ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
-DEB_BUILD_GNU_SYSTEM ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
 DEB_BUILD_GNU_TYPE = $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
@@ -69,10 +68,10 @@ ifeq (,$(findstring nostrip,$(DEB_BUILD_
 	   	debian/tmp/bin/tempfile
 endif
 
-ifneq ($(DEB_BUILD_GNU_SYSTEM),gnu)
+ifneq ($(DEB_HOST_ARCH_OS),hurd)
 	ln -s /bin/which debian/tmp/usr/bin/which
 endif
-ifeq ($(DEB_BUILD_ARCH_OS),linux)
+ifeq ($(DEB_HOST_ARCH_OS),linux)
 	mv debian/tmp/usr/sbin/installkernel debian/tmp/sbin/
 else
 	rm debian/tmp/usr/sbin/installkernel \

Bug#407192: dosfstools: uses obsolete dpkg argument

[Guillem Jover]

Package: dosfstools
Version: 2.11-2.1
Tags: patch

Hi,

This package is using at build time a deprecated dpkg option, which was
removed some time ago. Attached a patch that fixes this.

regards,
guillem
--- debian/rules	2007-01-16 21:11:49.0 +0200
+++ debian/rules	2007-01-16 21:12:45.0 +0200
@@ -19,9 +19,9 @@ tmpdir=debian/tmp
 docdir=$(tmpdir)/usr/share/doc/dosfstools
 mandir=$(tmpdir)/usr/share/man
 oldmandir=$(tmpdir)/usr/man
-ARCH = $(shell dpkg --print-gnu-build-architecture)
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
-ifeq ($(ARCH),alpha)
+ifeq ($(DEB_HOST_ARCH),alpha)
 OPTFLAGS="-fomit-frame-pointer -fno-strict-aliasing $(shell getconf LFS_CFLAGS)"
 else
 OPTFLAGS="-O2 -fomit-frame-pointer $(shell getconf LFS_CFLAGS)"

Bug#407196: openssl: please add armel support

[Guillem Jover]

Package: openssl
Version: 0.9.8c-4
Severity: wishlist
Tags: patch

Hi,

The attached patch adds support for armel, which is an arm little
endian variant of our current arm port but using the new EABI, which
may completely replace the arm port in the future.

regards,
guillem
--- Configure	2007-01-16 21:23:14.0 +0200
+++ Configure	2007-01-16 21:25:25.0 +0200
@@ -315,6 +315,7 @@ my %table=(
 "debian-alpha-ev5","gcc:-DTERMIO -O3 -mcpu=ev5 -g -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 DES_UNROLL:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 "debian-arm","gcc:-DL_ENDIAN -DTERMIO -O2 -g -Wall::-D_REENTRANT::-ldl:BN_LLONG DES_RISC1dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 "debian-armeb","gcc:-DB_ENDIAN -DTERMIO -O2 -g -Wall::-D_REENTRANT::-ldl:BN_LLONG DES_RISC1dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"debian-armel","gcc:-DL_ENDIAN -DTERMIO -O2 -g -Wall::-D_REENTRANT::-ldl:BN_LLONG DES_RISC1dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 #"debian-amd64","gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 "debian-amd64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK RC4_CHAR BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
 "debian-kfreebsd-amd64","gcc:-m64 -DL_ENDIAN -DTERMIOS -O3 -Wall -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK BF_PTR2 DES_INT DES_UNROLL:${x86_64_asm}:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

Bug#404672: rtorrent 0.7.0 is available

[Guillem Jover]

Hi,

While checking the updated packages I noticed that libtorrent10 Conflicts
and Replaces libtorren9, that's wrong, as both of them should be
co-installable, that's why they have a different package name and
different library filenames. Please fix this before uploading.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#387413: uniq-dctrl wanted

[Guillem Jover]

Hi,

At work I wrote some scripts to generate the delta status between two
distros in patch and version comparison forms. And I needed a
uniq-dctrl, which I implemented really cheaply with gawk. This of
course cannot be used as a general purpose tool and should probably
not be included in the package, but anyway others may find it useful,
or something. ;)

Attached the tiny script.

regards,
guillem
#!/usr/bin/gawk -f

BEGIN {
  RS=""
  FS="\n"
  old_pkg=""
  pkg=""
}

{
  # FIXME: We assume the Packages field is always the first one.
  pkg=$1
  if (old_pkg != pkg) {
print $0
print ""
old_pkg=$1
  }
}

Bug#356299: ping

[Guillem Jover]

Hi,

On Sun, 2007-01-21 at 19:11:12 +0100, Robert Millan wrote:
> Any news on this?   Can this patch still enter etch?

I don't think so.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#408201: apt: lzma support

[Guillem Jover]

Package: apt
Version: 0.6.46.4
Severity: wishlist
Tags: patch

Hi,

Now that dpkg has lzma support it would be nice to get this small
patch into apt for etch.

regards,
guillem
--- apt-inst/deb/debfile.cc	2006-03-02 16:06:31.0 +0200
+++ apt-inst/deb/debfile.cc	2006-11-03 05:29:03.0 +0200
@@ -48,8 +48,10 @@ debDebFile::debDebFile(FileFd &File) : F
   return;
}
 
-   if (!CheckMember("data.tar.gz") && !CheckMember("data.tar.bz2")) {
-  _error->Error(_("This is not a valid DEB archive, it has no '%s' or '%s' member"), "data.tar.gz", "data.tar.bz2");
+   if (!CheckMember("data.tar.gz") &&
+   !CheckMember("data.tar.bz2") &&
+   !CheckMember("data.tar.lzma")) {
+  _error->Error(_("This is not a valid DEB archive, it has no '%s', '%s' or '%s' member"), "data.tar.gz", "data.tar.bz2", "data.tar.lzma");
   return;
}
 }
@@ -134,6 +136,10 @@ bool debDebFile::ExtractArchive(pkgDirSt
   Member = AR.FindMember("data.tar.bz2");
   Compressor = "bzip2";
}
+   if (Member == 0) {
+  Member = AR.FindMember("data.tar.lzma");
+  Compressor = "lzma";
+   }
if (Member == 0)
   return _error->Error(_("Internal error, could not locate member"));   
if (File.Seek(Member->Start) == false)
--- apt-pkg/deb/debsrcrecords.cc	2006-03-02 15:44:28.0 +0200
+++ apt-pkg/deb/debsrcrecords.cc	2006-11-03 05:34:32.0 +0200
@@ -151,7 +151,7 @@ bool debSrcRecordParser::Files(vector

Bug#401153: backtrace for iasl bug #401153

[Guillem Jover]

found 401153 20060912-2
thanks

On Mon, 2006-12-04 at 19:53:49 +0100, Andreas Barth wrote:
> * Andreas Henriksson ([EMAIL PROTECTED]) [061204 19:44]:
> > I can confirm that the patch provided by Guillem Jover seems to fix
> > the testcase in the original bug-report for me on Debian Testing
> > PowerPC.
> 
> I would propose to upload the fixed package ASAP. In case you want, I
> can do an NMU as well.

Maybe I was not clear enough in my initial analysis, but this patch
was a partial fix, which just solved the segmentation fault, the
remaning problem is that the output is bogus, some of it needs to be
swapped on big-endian boxes to be little-endian. I'd say that's even
worse than the segfault as people may end up flashing bogus acpi data
to their proms!

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#402526: dpkg: please consider correcting insane timestamp in changelog file

[Guillem Jover]

tags 402526 pending
thanks

Hi,

On Sun, 2006-12-10 at 23:54:57 +, J S Bygott wrote:
> Package: dpkg
> Version: 1.13.24
> Severity: minor

> Actually, this is a bug in all versions since 1.4.0.20
> 
> The files 'changelog' and 'changelog.Debian' both contain an insane
> timestamp (year 2018 instead of 1998).  This confuses the automatic
> debian changelog tracking at
> 
> http://packages.debian.org/changelogs/pool/main/d/dpkg/dpkg_1.13.24/changelog
> 
> so that the list of versions in the grey panel on the top right starts with an
> entry for the year 2018.

Yes, I actually fixed this some weeks ago, it's in the svn repo, and
will go in the next release.

> Now, I realise that changing changelog entries is probably a bad thing
> in general. (If it's problematic, maybe ask on d-d?)  I would have
> thought it would be okay in to change it in this exceptional case?

I don't have any problem in general fixing wrong changelog entries...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#403216: dpkg-shlibdeps: Fails to check /emul/ia32-linux/[usr/]lib

[Guillem Jover]

tags 403216 - patch
thanks

On Fri, 2006-12-15 at 13:26:41 +0100, Goswin von Brederlow wrote:
> Package: dpkg-dev
> Version: 1.13.24
> Severity: critical
> File: /usr/bin/dpkg-shlibdeps
> Tags: patch

Er, there's not patch in here... and I think the proposed fix is
wrong.

> dpkg-shlibdeps sets
> 
> my @librarypaths = qw( /lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64 );
> 
> to include the 32bit libraries on ia64 and amd64. But packages install their
> libraries in /emul/ia32-linux/[usr/]lib to which [/usr]/lib is a link.

> The problem now is that dpkg will not find the package for a library
> under [/usr]/lib32/ as it was installed under a different path. This
> causes dpkg-shlibdeps to not find a package for 32bit libraries and no
> shlibs file. In the end the packages will lack the neccessary depends
> to the 32bit libraries used in the package.

It could be argued that the handling of this biarch stuff is a mess,
but anyway. This was fixed in the past when we gave dpkg-shlibdeps
support to handle /lib/ldconfig/ symlinks. Now it's gone, so the
proper fix is for the package providing such libs in such nasty
paths to add a file under /etc/ld.so.conf.d with those, and for
dpkg-shlibdeps to read those files. I'll implement that tomorrow
or the day after (I'm traveling today).

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396979: parchive: typo in package description

[Guillem Jover]

Package: parchive
Version: 1.1-4
Severity: minor

Hi,

The package description reads:

 [...]
 supports the 'Reed-Soloman Code' implementation that allows for recovery of
 [...]

It should be 'Reed-Soloman Code' -> 'Reed-Solomon Code'.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#38334: Duplicate bug?

[Guillem Jover]

Hi Tomas,

On Sun, 2006-11-05 at 00:49:33 +0100, Tomas Pospisek wrote:
> Package: dpkg
> Version: 1.13.22
> Followup-For: Bug #38334
> 
> So is this bug a duplicate of #260696 and could be closed?

Well yes and no, it's a duplicate but probably the other one should
not have been closed, just merged with this. dpkg supports
backgrounding (which is the default as Frank said on the other bug
report) and making a subshell (done when the env var NOJOBCTRLSTOPENV
is set). So this should be fixed, either by removing the background
stuff, or by showing the proper message.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#401153: backtrace for iasl bug #401153

[Guillem Jover]

Hi,

Mattia I'm sorry you got this, after I asked to enable iasl on all
arches to be able to use it in qemu. I started investigating this
last week or so, but didn't file a bug report because I've not come
yet with a complete solution. Below my current analysis anyway, if
I've time I'll try to come up with a full fix...

On Sun, 2006-12-03 at 13:13:19 +0100, Mattia Dongili wrote:
> On Sat, Dec 02, 2006 at 02:27:40AM +0100, Andreas Henriksson wrote:
> > On fre, 2006-12-01 at 15:43 -0800, Moore, Robert wrote:
> > > I'm not sure I understand what you are describing, please clarify.

> > Please see http://bugs.debian.org/401153 for the original bug
> > report. Basically, iasl successfully compiles the atteched dsl
> > file on a regular i386 pc, but when running the same program on
> > PowerPC (Debian GNU/Linux) then you get a segmentation fault. There
> > is probably a bug in the program somewhere which seems to only
> > trigger on powerpc at the moment.
> > 
> > It has been tracked down to being related to Asl.Value.String being
> > NULL. This state seems invalid and makes the program crash. Do you
> > have any idea what might have failed and how this variable could be
> > uninitialized? It would be really appreciated if you have any hints
> > about possible failures that we can investigate...

This is a problem of endinaness. iasl does not work on big-endian
boxes. The main issue is that the bison parser is using Value.Integer
(which is an ACPI_INTEGER and in 32 bit arches it's a 64 bit type) to
assign the values to the union ACPI_PARSE_VALUE. And then when accessing
the pointers or the 'Size' variable it gets only the MSW, which is 0,
so my workaround has been to define that we cannot use a 64 bit type
for ACPI_INTEGER on 32 bit arches. Ideally the union should be filled
using the proper member. This fixes the segfault.

There's mentions in the changes.txt from 2003 of added support for
big-endian systems, which was the first thing I tried, to enable the
ACPI_BIG_ENDIAN macro for those arches (that's included in the patch
anyway), but this didn't help. I suppose the code has evolved since
then and that support has been lost because no one run it on such
arches.

Then the next problem is that iasl generates output, but that output
is wrong. The output needs to be swapped to make it little-endian.
AFAIS the problem is located in compiler/aslcodegen.c in most of the
functions that are using CgLocalWriteAmlData, as they should be
converting those values to little-endian when writting. But it didn't
feel right to keep the TableHeader stored as little-endian in memory,
as some other parts of the code use and reference it. So problably
this needs to be swapped when dumping to the disk.

> Just as a side note, I tried compiling the mentioned DSDT on an ARM
> platform and I get a different error:

I was trying it on arm little endian and it worked, the same for
mipsel.

The attached patch fixes the segfault, and corrects the CFLAGS
handling for upstream and Debian, it also adds alpha to the list of
64 bit arches. The fix for compiler/aslopcodes.c is needed because
the macros ACPI_UINT32_MAX: and ACPI_INTEGER_MAX are the same if
ACPI_INTEGER is defined to be 32 bits.

regards,
guillem
diff -ur acpica-unix-20060912.orig/compiler/aslopcodes.c 
acpica-unix-20060912/compiler/aslopcodes.c
--- acpica-unix-20060912.orig/compiler/aslopcodes.c 2006-09-12 
20:49:25.0 +0300
+++ acpica-unix-20060912/compiler/aslopcodes.c  2006-11-27 09:40:52.0 
+0200
@@ -329,6 +329,7 @@
 }
 break;
 
+#ifndef ACPI_NO_INTEGER64_SUPPORT
 case ACPI_INTEGER_MAX:
 
 /* Check for table integer width (32 or 64) */
@@ -341,6 +342,7 @@
 return 1;
 }
 break;
+#endif
 
 default:
 break;
diff -ur acpica-unix-20060912.orig/compiler/Makefile 
acpica-unix-20060912/compiler/Makefile
--- acpica-unix-20060912.orig/compiler/Makefile 2006-09-12 20:49:26.0 
+0300
+++ acpica-unix-20060912/compiler/Makefile  2006-11-27 06:48:01.0 
+0200
@@ -89,7 +89,8 @@
../osunixxf.c
 
 NOMAN= YES
-CFLAGS+= -Wall -O2 -Wstrict-prototypes -D_LINUX -DACPI_ASL_COMPILER 
-I../include 
+MK_CFLAGS = -DACPI_ASL_COMPILER -I../include
+CFLAGS= -Wall -Wstrict-prototypes -O2
 
 #YACC= yacc
 YACC=  bison
@@ -103,6 +104,9 @@
 #CFLAGS+= -D_USE_BERKELEY_YACC
 #.endif
 
+%.o: %.c
+   $(CC) $(MK_CFLAGS) $(CFLAGS) -c -o $@ $<
+
 aslmain : $(patsubst %.c,%.o, $(SRCS))
$(CC) $(LDFLAGS) $(patsubst %.c,%.o, $(SRCS)) \
$(LOADLIBES) $(LDLIBS) -o iasl
diff -ur acpica-unix-20060912.orig/debian/rules 
acpica-unix-20060912/debian/rules
--- acpica-unix-20060912.orig/debian/rules  2006-11-27 06:38:05.0 
+0200
+++ acpica-unix-20060912/debian/rules   2006-11-27 06:40:31.0 +0200
@@ -32,7 +32,7 @@
 
# Commands to compile the package.
cd compiler && \
-   $(MAKE) && \
+   $(MAKE) CFLAGS="$(CFLAGS)" &

Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

[Guillem Jover]

reassign 400372 linux-image-2.6.18-3-sparc32
thanks

Included most of the relevant discussion for the kernel team's benefit.

On Sun, 2006-11-26 at 10:19:39 +0100, BERTRAND Joël wrote:
> Guillem Jover a écrit :
> >On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:
> > > Package: dpkg
> > > Version: 1.13.24
> > > Architecture: sparc
> > > Severity: grave

> > > I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
> > > of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
> > > If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
> > > dpkg because it craches with a random error when it tries to configure
> > > the package (it cannot read the configuration script due to a data
> > > corruption. Sometimes, an EOF in the middle of the script...).
> > >
> > > I have tested dpkg on three SS20 that perfectly work with SuperSPARC
> > > and with four different HyperSPARC modules, and with and without HIGHMEM.
> > >
> > > Results : in all configurations (with and without HIGHMEM), dpkg
> > > crashes with HyperSPARC and works with SuperSPARC. I don't understand
> > > this memory corruption because the workstations work fine in all
> > > configurations I have tested ! Kernels are 2.6.18.x.

> > Given that this happens when changing the CPU, and that this does not
> > happen anywhere else, I'd say it's a hw or kernel problem. Also given
> > the mails[0] in debian-sparc about past state of HyperSparc support I
> > would say this is not related to dpkg, and the bug would need closing
> > or to be reassigned. But I've CCed debian-sparc for comments.
> >
> > [0] <http://lists.debian.org/debian-sparc/2006/04/msg3.html>
> ><http://lists.debian.org/debian-sparc/2006/04/msg00018.html>
> ><http://lists.debian.org/debian-sparc/2006/06/msg00030.html>

>   I know these mails and I have contributed to the sparc32 smp support 
> (and ESP module debug). Today, the ESP works fine (since 2.6.18) and the 
> HyperSPARC support seems to works too. Only on trouble with a 2.6.18 
> kernel with pipes() :
> 
> Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
> dereference
> Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->context = 5058
> Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->pgd = fc12d000
> Nov 23 14:26:48 hilbert kernel:   \|/  \|/
> Nov 23 14:26:48 hilbert kernel:   "@'/ ,. \`@"
> Nov 23 14:26:48 hilbert kernel:   /_| \__/ |_\
> Nov 23 14:26:48 hilbert kernel:  \__U_/
> Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
> Nov 23 14:26:48 hilbert kernel: PSR: 40c2 PC: f008bd8c NPC: f008bd90 Y: 
> Not tainted
> Nov 23 14:26:48 hilbert kernel: PC: 
> Nov 23 14:26:48 hilbert kernel: %%G: 1000 fbbfea14  003c 0030  
> fbbfea00 73635f6c  f93be000 
> Nov 23 14:26:48 hilbert kernel: %%O: f0a0d900 f0a0d900  fcffb000 63616368  
> 6536345f 70616765  f93bfd88 f008c030
> Nov 23 14:26:48 hilbert kernel: RPC: 
> Nov 23 14:26:48 hilbert kernel: %%L:    fbbfea50 fbbfea00  
>  fcffc000  0001 0001
> Nov 23 14:26:48 hilbert kernel: %%I: f93bfe60 0003  f93bfe60 1800  
> fcffb000   f93bfe00 f008c140
> Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
> Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
> Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
> Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
> syscall_is_too_hard+0x3c/0x40
> Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98
> 
>   But whit bug is very strange, it only occurs with dpkg. It is not a 
> material failure because I can see it with all couple off HyperSPARC, 
> memory and motherboard. And I cannot see any trace in the logs. All 
> daemons, all programs I use work fine on the same station.

I don't think you can expect userland to cope well if pipe is crashing
in the kernel, thus reassigning.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405570: qemu: non-passive FTP does not work

[Guillem Jover]

Hi,

On Thu, 2007-01-04 at 19:21:34 +0300, Stanislav Maslovski wrote:
> Sorry, the report came out without an explanatory text. It follows now:

No problem.

> Below is the log of an FTP connection started from the GUEST (qemu started
> with -net user):
> 
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "230 Login successful."
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "SYST"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "215 UNIX Type: L8"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "PWD"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "257 "/""
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "TYPE I"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "200 Switching to Binary mode."
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "REST 0"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "350 Restart position accepted (0)."
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "PORT 10,0,2,2,12,146"
> Thu Jan  4 18:10:18 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "500 Illegal PORT command."
> Thu Jan  4 18:10:29 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "PWD"
> Thu Jan  4 18:10:29 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "257 "/""
> Thu Jan  4 18:10:29 2007 [pid 14469] [ftp] FTP command: Client "X.X.X.X", 
> "PORT 10,0,2,2,15,107"
> Thu Jan  4 18:10:29 2007 [pid 14469] [ftp] FTP response: Client "X.X.X.X", 
> "500 Illegal PORT command."
> 
> It is seen that the virtual address 10.0.2.2 is used in the PORT command
> instead of the host address.
> 
> The attached patch enables FTP emulation on 21 port in the slirp code.
> It also corrects a couple of slirp bugs with obtaining the right host IP.
> 
> TODO: add a command line option.
> 
> =
> 
> The patch itself is in the original report.


I'll be checking this later once etch is released and we can start
doing changes to unstable again.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405668: dkpg: dpkg -l does not show entire version string

[Guillem Jover]

forcemerge 179913 405668
thanks

On Fri, 2007-01-05 at 15:42:26 +0200, Siim Põder wrote:
> Package: dkpg
> Version: 1.13.24
> Severity: minor
> 
> bsdutils package version is "1:2.12p-4sarge1" but dpkg -l cuts off the
> "1:" part and just shows "2.12p-4sarge1".

This bug has been reported several times already.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#405045: dh_buildpackage (or maybe dpkg-deb) output an weired tar error

[Guillem Jover]

package dpkg-dev
forcemerge 375749 405045
thanks

On Sat, 30 Dec 2006 19:12:07 +0100, Michelle Konzack wrote:
> Package: debhelper
> Version: 5.0.37.3
> Severity: normal
> Tags: etch

> My Etch Devel-Station produce every time the following error while
> building and it does definitivly not depend an a source package

> -- System Information
> Versions of the packages debhelper depends on:
> ii  dpkg-dev   1.13.21package building tools for Debian

Your etch system by that time was fairly outdated (at least regarding
dpkg), and the version fixing this had been there for months. Please keep
your system updated when filing bug reports.

> 8<--
> dh_builddeb
> dpkg-deb: baue Paket »menu« in »../menu_2.1.31etch1_i386.deb«.
> tar: -: file name read contains nul character
>  signfile menu_2.1.31etch1.dsc

> You need a passphrase to unlock the secret key for
> 8<--

> The severity is only normal, since the packages are
> build correctly and can be installed on any systems.

This should be minor as it was actually a warning, anyway, merging with
the other closed bugs, so this one will be closed with them...

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406932: bulmages: wrong use of virtual packages

[Guillem Jover]

Package: bulmages
Version: 0.5.9+svn20061021+20061210-1

Hi,

Some binary packages from the bulmages source are wrongly using
virtual packages to describe relationships.

libbulmalib0 Provides and Conflicts with libbulmalib, which makes it
uninstallable in parallel with possible different versions of the
library with a different soname (otherwise the binary package name with
the soname there does not make sense). libbulmalib0-dev is depending
on this virtual package without any real package as a first option.
Also this might cause to use the wrong headers for the wrong library.

The metapackage bulmages is Depending on the virtual package as well,
which is wrong in two ways, first, if it's not depending on it
directly, it should not be listed there, and second, if it depended
on it but you had to list it manually (say it's being dlopen:ed),
then you would need to specify the real package name.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#162348: Build tools don't support non-standard admin directory

[Guillem Jover]

reopen 162348
thanks

On Sun, 2006-07-09 at 11:30:02 +0200, Nicolas François wrote:
> Version: 1.13.18

> On Thu, Sep 26, 2002 at 12:36:54AM +0200, Henning Spruth wrote:
> > I'm trying to use dpkg to build and package software for the VR3 Linux PDA. 
> > To 
> > do so, I need to install the package on the host relative to some base 
> > directory, I also need to keep the package admin data for these PDA files 
> > separate.

> > 2. dpkg-buildpackage doesn't allow to specify the admin directory, which is 
> > required for dpkg-parsechangelog and dpkg-checkbuilddeps
> 
> dpkg-parsechangelog do not uses the admin directory (/var/lib/dpkg), but
> the library directory (/usr/lib/dpkg).
> 
> For dpkg-checkbuilddeps, see below.
> 
> > 3. dpkg-checkbuilddeps does't have a switch to specify the admin directory
> 
> Also, I don't think dpkg-checkbuilddeps should check the dependencies
> regarding a non standard admin directory (the programs need to be
> installed in the host building the package, not on the target host)

I agree it should not check the dependencies there by default, but the
admin should be free to change this kind of stuff, in the same way
that is allowed with the other commands.

> Hence, I'm closing this bug.

I'm reopening the bug, and will commit now the few changes that will
fix this.

> To build a package for another target, I recommend a chroot, or dpkg-cross.

That's a fine preference, but sometimes you may want to avoid having
to run commands inside a chroot. And about dpkg-cross, I think its
functionality should be merged back into dpkg.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#406931: libbulmalib0-dev: missing header files

[Guillem Jover]

Package: libbulmalib0-dev
Version: 0.5.9+svn20061021+20061210-1
Severity: important

Hi,

This package does not contain any header file, which will make life of
possible developers using it a bit hard.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#399868: CFLAGS not passed to configure

[Guillem Jover]

package libcairo
tags 399868 patch
thanks

Hi Tommi, Dave,

I'm including a new patch which always passes -g (per policy, packages
_should_ include debugging symbols in the build tree), and with the
previous patch this was a regression, changes the deprecated debug
DEB_BUILD_OPTIONS to noopt, passes the flags in the command line
instead of using env, and does not pass LDFLAGS as it's not defined
in the rules file. It'd be good to add -Wall to the first CFLAGS
assignations, though.

There's some other things in the rules file which could be fixed

  - DH_COMPAT should be a temporary override over debian/compat.
  - INSTALL_PROGRAM can be removed, as you don't use it, and debhelper
takes care of this.
  - the CONFFLAGS stuff is written for autoconf 2.13, but the package
uses autoconf 2.60.
  - there's some other unused variables and PHONY targets.
  - the references to directfb -dev package versions are outdated.

and I could file a bug report with a patch if you want, Dave.

regards,
guillem
--- debian/rules2006-11-24 03:53:22.0 +0200
+++ debian/rules2006-11-24 03:57:48.0 +0200
@@ -48,10 +48,15 @@ export DH_COMPAT=5
 export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
-   CFLAGS += -g -O0
+CFLAGS = -g
+CFLAGS_UDEB = -g
+
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+   CFLAGS += -O0
+   CFLAGS_UDEB += -O0
 else
CFLAGS += -O2
+   CFLAGS_UDEB += -Os
 endif
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
@@ -93,7 +98,9 @@ configure-main-stamp: configure-common-s
dh_testdir
mkdir -p $(MAIN_BUILD_DIR); \
cd $(MAIN_BUILD_DIR); \
-   $(SRC_DIR)/configure $(CONFFLAGS) \
+   $(SRC_DIR)/configure \
+   CFLAGS="$(CFLAGS)" \
+   $(CONFFLAGS) \
--prefix=$(prefix) \
--mandir=$(share)/man \
--infodir=$(share)/info \
@@ -105,7 +112,9 @@ configure-udeb-stamp: configure-common-s
dh_testdir
mkdir -p $(DIRECTFB_BUILD_DIR); \
cd $(DIRECTFB_BUILD_DIR); \
-   $(SRC_DIR)/configure $(CONFFLAGS) \
+   $(SRC_DIR)/configure \
+   CFLAGS="$(CFLAGS_UDEB)" \
+   $(CONFFLAGS) \
--prefix=$(DIRECTFB_PREFIX) \
--mandir=$(share)/man \
--infodir=$(share)/info \

Bug#399343: dpkg: [INTL:vi] Vietnamese program translation update

[Guillem Jover]

Hi,

On Sun, 2006-11-19 at 22:06:24 +1030, Clytie Siddall wrote:
> Package: dpkg
> Version:
> Severity: minor
> Tags: l10n, patch
> 
> The updated Vietnamese translation for the Debian Installer Level 5
> program file: dpkg
> 
> This is my reviewed translation for Etch. :)

I'm preparing the next and supposedly last dpkg upload, and this po
seems to have lost 4 strings, could you check that please? I could
restore them from the previous .po but I'm not sure if there may be
other problems with the updated one.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#393924: rmadison: does not report version correctly in some cases

[Guillem Jover]

tags 107449 - wontfix
merge 393924 107449
thanks

Hi,

> 2006/11/9, Julian Gilbey <[EMAIL PROTECTED]>:
> > I'm reopening this bug report and reassigning it to dpkg, as dpkg -l
> > doesn't display epochs, and this is another example of why it should.
> >
> > There is a patch in the BTS which makes dpkg -l display epochs.

I'll be fixing it for lenny.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#391183: dpkg: start-stop-daemon should hand up daemon exit code

[Guillem Jover]

tags 391183 moreinfo
thanks

On Thu, 2006-10-05 at 11:39:43 +0200, Marc Haber wrote:
> Package: dpkg
> Version: 1.13.22
> Severity: wishlist
> 
> There should be a possibility to get ahold of the exit code given by
> the binary invoked by start-stop-daemon.

In which conditions would you want that? If the binary supports
daemonization we can only get the exit code if it exits before the
daemonization. If it does not support daemonization and we are using
s-s-d's background option then we can only get the exit code if we
keep the parent s-s-d running and waiting for the child, and then
I don't understand why we would want to use the background option.

Could you clarify?

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400379: angrydd: Missing dependency on python-numeric

[Guillem Jover]

Package: angrydd
Version: 1.0.1-1
Severity: important

Hi,

The package is missing a dependency on python-numeric, which is being
using through the surfarray stuff from python-pygame.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400381: dissy: missing dependencies on binutils and python-gtk2

[Guillem Jover]

Package: dissy
Version: 3-1
Severity: serious

Hi,

This package is a frontend for objdump, readelf and nm, but it does
not depend on binutils. It's lacking dependencies at least also on
python-gtk2. Please check if anything else is missing before
uploading.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400384: varnish: leaves files around on purge

[Guillem Jover]

Package: varnish
Version: 1.0.2-2

Hi,

On purge the package leaves /var/lib/varnish/varnish_storage.bin.

Also the package does not cleanup the temporary files /tmp while using
gcc at runtime.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400387: apf: misplaced dot in package long descriptions

[Guillem Jover]

Package: apf
Version: 0.8.2-1
Severity: minor

Hi,

The long package descriptions contain a misplaced dot just before the
Homepage pseudo-field. The dot should be placed in the second column,
not the third.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#400372: dpkg randomly craches on Sparc32 running HyperSPARC processor

[Guillem Jover]

Hi,

On Sat, 2006-11-25 at 19:19:58 +0100, BERTRAND Joël wrote:
> Package: dpkg
> Version: 1.13.24
> Architecture: sparc
> Severity: grave

> I have some SparcSTATION 20 with one or two SuperSPARC-II and 448 MB
> of memory (thus, HIGHMEM is used). On these workstations, dpkg works fine.
> If I replace SuperSPARC-II by one, two or four ROSS RT-626, I cannot use
> dpkg because it craches with a random error when it tries to configure
> the package (it cannot read the configuration script due to a data
> corruption. Sometimes, an EOF in the middle of the script...).
>
> I have tested dpkg on three SS20 that perfectly work with SuperSPARC
> and with four different HyperSPARC modules, and with and without HIGHMEM.
>
> Results : in all configurations (with and without HIGHMEM), dpkg
> crashes with HyperSPARC and works with SuperSPARC. I don't understand
> this memory corruption because the workstations work fine in all
> configurations I have tested ! Kernels are 2.6.18.x.

Given that this happens when changing the CPU, and that this does not
happen anywhere else, I'd say it's a hw or kernel problem. Also given
the mails[0] in debian-sparc about past state of HyperSparc support I
would say this is not related to dpkg, and the bug would need closing
or to be reassigned. But I've CCed debian-sparc for comments.

[0] 



regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#391183: dpkg: start-stop-daemon should hand up daemon exit code

[Guillem Jover]

On Fri, 2006-11-24 at 10:20:05 +0100, Marc Haber wrote:
> On Fri, Nov 24, 2006 at 05:34:56AM +0200, Guillem Jover wrote:
> > On Thu, 2006-10-05 at 11:39:43 +0200, Marc Haber wrote:
> > > Package: dpkg
> > > Version: 1.13.22
> > > Severity: wishlist
> > > 
> > > There should be a possibility to get ahold of the exit code given by
> > > the binary invoked by start-stop-daemon.
> > 
> > In which conditions would you want that? If the binary supports
> > daemonization we can only get the exit code if it exits before the
> > daemonization.

> Yes, and that would be desireable. Some packages (ab)use s-s-d to
> invoke a binary under a different account without creating syslog
> entries that might be confusing to users, and when that binary returns
> an exit code, we'd like to see it.

Well, then I think I still don't understand what's the problem, if
exim_tidydb is not daemonizing, then s-s-d will just exec it, and
you'll get its exit code if it terminates.

zulo:~# start-stop-daemon --start --exec /bin/true --chuid bin:bin;echo $?
0
zulo:~# start-stop-daemon --start --exec /bin/false --chuid bin:bin;echo $?
1

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]