Re: On including 64-bit libs in 32-bit packages (see #344104)

[Stanislav Maslovski]

On Sat, Oct 21, 2006 at 03:18:45PM -0600, Bruce Sass wrote:
> On Sat October 21 2006 13:35, Darren Salt wrote:
> > I demand that Hendrik Sattler may or may not have written...
> > > 64bit kernels are not available in the i386 archive. That makes the
> > > 64bit libs rather useless, doesn't it?
> >
> > No - you could be using a locally-built 64-bit kernel.
> 
> Perhaps i386 needs something along the lines of localepurge for 64bit 
> stuff.

Yup, I had a similar idea.

-- 
Станислав

Bug#394603: ITP: cl-chunga -- Portable chunked streams for Common Lisp

[Peter Van Eynde]

Package: wnpp
Severity: wishlist
Owner: Peter Van Eynde <[EMAIL PROTECTED]>

* Package name: cl-chunga
  Version : 0.2.0
  Upstream Author : Dr. Edmund Weitz
* URL : http://weitz.de/chunga/
* License : BSD
  Programming Lang: Common Lisp
  Description : Portable chunked streams for Common Lisp

 Chunga implements streams capable of chunked encoding on demand as defined
 in RFC 2616. For an example of how these streams can be used see Drakma.
 .
 Chunga is currently not optimized towards performance - it is rather intended
 to be easy to use and (if possible) to behave correctly.
 .
  Homepage: http://weitz.de/chunga/


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Bug mass filling

[Russ Allbery]

(Yes, I'm on vacation, and really am still on vacation, but I had a brief
check-in moment and happened to see this thread.  Note that I probably
won't see responses, unless I get to them tomorrow night, until the
beginning of November.)

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of
> maintainers are uploading their packages, and don't really care with the
> policy.

> Maybe some errors (E:) of lintian could be changed to critical (C:) and
> uploads containing such critical errors be refused by dak? What do you
> think?

Please note that lintian considers *any* violation of policy, even things
that in practice won't cause problems, to be worthy of E:.  In this
particular case:

> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?

what's generally going on is that the package builds only arch-dependent
or arch-independent packages and therefore the missing target is a no-op.
Due to the way that the autobuilders work and the normal package building
tools work, in practice this will almost never be noticed.  However,
policy *does* require that the targets exist, so lintian dutifully
diagnoses the problem.

Another common lintian error that doesn't cause problems in practice (now)
is that lintian intentionally does not take transitive dependencies into
account when checking package dependencies and build dependencies.  This
means that if, for instance, your debian/rules calls a program from
po-debconf, lintian will complain if you don't build-depend on po-debconf,
even if you're already build-depending on debhelper which in turn
build-depends on po-debconf.  This is because reliance on transitive
dependencies in general creates dormant RC bugs.  If for some reason (and
I realize that this is unlikely, but one can construct reasons why it
might happen) debhelper drops or downgrades its dependency on po-debconf,
all those packages that just relied on debhelper to pull in po-debconf
immediately are RC-buggy.  Adding an explicit dependency is easy and
avoids this problem.

(If, however, a package is *defined* as being equivalent to depending on
another package, I'm willing to teach lintian about those special cases,
the same as how it handles virtual packages like c-shell now.)

I've put a lot of work into lintian over the past six months focused
specifically on eliminating false positives, so I'd love it if people
would run the unstable lintian regularly on packages and report as bugs
any false positives that don't look unavoidable.  (lintian -i will often
give you clues as to whether the false positive is unavoidable; if lintian
-i specifically recommends an override, that generally means that the
lintian maintainers believe it infeasible to entirely avoid false
positives there.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#394586: ITP: autoplayiso -- allows creating multimedia CD/DVD images that play automatically

[Jeremias Casteglione]

Package: wnpp
Severity: wishlist
Owner: Jeremias Casteglione <[EMAIL PROTECTED]>

  Package name: autoplayiso
  Version : 0.1-1
  Upstream Author : Rafael Ignacio Zurita <[EMAIL PROTECTED]>
  URL : http://amidamaru.homelinux.org/debian/debs/
  License : GPL
  Description : allows creating multimedia CD/DVD images that play 
automatically

The autoplayiso is a smaller version of Limp with an autoplay feature.
It is configured to automatically play multimedia files if these are in
the same CD.

Also, this project has a script named mkautoplayiso to create CDs with
autoplay-Limp inside.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-k7
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to es_AR.UTF-8)


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

Re: Bug mass filling

[Manoj Srivastava]

On Sun, 22 Oct 2006 09:28:54 +1000, Anthony Towns  
said: 

> On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
>> Gee. Don't we already have something very like this?

>> These classifications are roughly equivalent to the bug severities
>> _serious_ (for _must_ or _required_ directive violations), _minor_,
>> _normal_ or _important_ (for _should_ or _recommended_ directive
>> violations) and _wishlist_ (for _optional_ items).  [2]

> Those classifications haven't been monitored or updated, so no, we
> don't.

Yes, we do. You seem to be conflating the severity and RC-ness
 of a bug --  bugs have severities, and the release team decides which
 bugs are RC or not.

> IIRC that changed pretty soon after woody's release, with the
> creation of a specific list of RC criteria maintained by the release
> team. The woody policy addenda [0], for instance, said:

>   Bashisms generally aren't release-critical, even when they're
>   in scripts marked #!/bin/sh. They may be release-critical if
>   their breakage causes other problems that are release-critical
>   if they ever happen.

> In contrast, policy still states:

>  Thus, shell scripts specifying `/bin/sh' as interpreter should
>  only use POSIX features.  If a script requires non-POSIX
>  features from the shell interpreter, the appropriate shell must
>  be specified in the first line of the script (e.g.,
>  `#!/bin/bash')

> Is a bashism in a /bin/sh script a normal bug ("should only use
> POSIX features"), or a RC bug ("the appropriate shell bust be
> specified")? It's much easier to work out by just looking at the
> rc_policy text file maintained by the RM team [1].

Neither. It is a non RC serious bug.

manoj
-- 
Quod erat demonstrandum. [Thus it is proven.  For those who wondered
WTF QED means.]
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#394585: ITP: hoz -- file splitter that uses the hacha file format

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: hoz
  Version : 1.65
  Upstream Author : Gustavo Picon <[EMAIL PROTECTED]>
* URL : http://hoz.sourceforge.net/
* License : GPL
  Programming Lang: C
  Description : file splitter that uses the hacha file format

 HOZ is a file splitter, which uses the same file format as the popular
 'Hacha' program.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

arches and etch

[Camm Maguire]

Greetings, and thank you all so much for your usual fantastic work on
Debian! 

I just wanted to make a few observations about the recent decision to
scrap m68k from etch:

1) The 4.x C compiler and hppa and apparently arm are currently much
   worse. 
2) kernel and/or libc bugs preventing any profiling program from
   invoking 'system' persist on mips(el) and hppa
3) alpha apparently has a kernel or other bug that corrupts
   denormalized numbers when passed as function arguments.
4) For a significant amount of time after the security compromise, we
   still have no standard ssh access to Debian alpha and arm machines
   for the purposes of fixing bugs.  I've had to rely on
   friends/accounts on other machines to fill in here.
5) Code which I had which compiled on all 11 sarge arches was
   summarily thrown out of testing apparently due to its failure to
   compile under new buggy gcc on some of these machines.  If we are
   looking for a fair standard, I would suggest that an arch would
   have at least to compile what it did in the previous release to be
   a candidate for the next, and that until it does, it should not
   cause the ejection of code which had not changed from the prior
   release. 
6) the m68k people have always been incredibly helpful and responsive,
   while it is quite difficult to get replies concerning several of
   the other arches, at least for me.  
7) Perhaps we should consider the balance between making debian just
   another glitzy quick-release plaything for mass consumption and
   minimal user contribution, and a system designed to give users who
   care and contribute the flexibility and power to do their work which
   so greatly benefits us all.

These are just my thoughts.  I've been a Debian developer for over ten
years, but recognize that I don't have as much information on these
issues as others in the project.  I will of course continue to support
whatever course the Debian organizational structure feels is best in
this regard.

Take care,
-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


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

Re: Bug mass filling

[Anthony Towns]

On Sat, Oct 21, 2006 at 03:40:28PM -0500, Manoj Srivastava wrote:
> Gee. Don't we already have something very like this? 

>  These classifications are roughly equivalent to the bug severities
>  _serious_ (for _must_ or _required_ directive violations), _minor_,
>  _normal_ or _important_ (for _should_ or _recommended_ directive
>  violations) and _wishlist_ (for _optional_ items).  [2]

Those classifications haven't been monitored or updated, so no, we don't.

IIRC that changed pretty soon after woody's release, with the creation of
a specific list of RC criteria maintained by the release team. The woody
policy addenda [0], for instance, said:

Bashisms generally aren't release-critical, even when they're in
scripts marked #!/bin/sh. They may be release-critical if their
breakage causes other problems that are release-critical if they
ever happen.

In contrast, policy still states:

 Thus, shell scripts specifying `/bin/sh' as interpreter should only
 use POSIX features.  If a script requires non-POSIX features from the
 shell interpreter, the appropriate shell must be specified in the
 first line of the script (e.g., `#!/bin/bash')

Is a bashism in a /bin/sh script a normal bug ("should only use POSIX
features"), or a RC bug ("the appropriate shell bust be specified")? It's
much easier to work out by just looking at the rc_policy text file
maintained by the RM team [1].

Cheers,
aj

[0] http://people.debian.org/~ajt/woody_policy_addenda.txt
[1] http://release.debian.org/etch_rc_policy.txt



signature.asc
Description: Digital signature

Re: Bug#394566: ITP: conkeror -- completely keyboard driven Gecko based web browser

[Axel Beckert]

Hi,

On Sun, Oct 22, 2006 at 12:54:10AM +0200, Isaac Clerencia wrote:
> > * Package name: conkeror
>
> I would really like if you choose a less misleading name, like
> mozilla-firefox-conkeror , just like the webdeveloper extension is
> named.

Yeah, I already wondered about the really misleading name. But I just
hadn't a better idea for a package name and so have chosen the
straight one.

But you're right, I should better name it "firefox-conkeror" (since
all the mozilla-firefox-* packages seemed to have been renamed to
firefox-*).

> It's quite nice to see that while the Mozilla foundation are really
> picky about their names, they don't seem to care at all about other
> app (even open source ones) names.

.oO( Phoenix, Firebird, ... )

Well, yes, you're right about the Mozilla Foundation.

But Conkeror is no Mozilla Foundation project, it's just a Firefox
extenstion with a strange name and hosted at some site, which also
seems to have no affiliation with the Mozilla Foundation. It's rather
it's own foundation, see http://www.mozdev.org/about.html as we
http://www.mozdev.org/faq.html#mozilla.

Regards, Axel
-- 
Axel Beckert - [EMAIL PROTECTED] - http://abe.home.pages.de/


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

Re: Bug#394566: ITP: conkeror -- completely keyboard driven Gecko based web browser

[Isaac Clerencia]

On Saturday, 21 October 2006 23:44, Axel Beckert wrote:
> Package: wnpp
> Owner: Axel Beckert <[EMAIL PROTECTED]>
> Severity: wishlist
>
> * Package name: conkeror
I would really like if you choose a less misleading name, like 
mozilla-firefox-conkeror , just like the webdeveloper extension is named.

It's quite nice to see that while the Mozilla foundation are really picky 
about their names, they don't seem to care at all about other app (even open 
source ones) names.

Best regards
-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgp9OEVQA6a0k.pgp
Description: PGP signature

Re: Bug#394566: ITP: conkeror -- completely keyboard driven Gecko based web browser

[Hendrik Sattler]

Am Samstag 21 Oktober 2006 23:44 schrieb Axel Beckert:
> * Package name    : conkeror

Is the misleading name (sounds too much like "konqueror") chosen 
intentionally?

HS


pgpQfxNBEMKqF.pgp
Description: PGP signature

Bug#394566: ITP: conkeror -- completely keyboard driven Gecko based web browser

[Axel Beckert]

Package: wnpp
Owner: Axel Beckert <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: conkeror
  Version : 0.34
  Upstream Author : Shawn Betts <[EMAIL PROTECTED]>
* URL : http://conkeror.mozdev.org/
* License : MPL or OSI-approved[1]
  Programming Lang: JavaScript, XUL
  Description : completely keyboard driven Gecko based web browser

Conkeror is a Gecko based and completely keyboard driven web browser
implemented as Firefox extension[2]. It has no toolbars or buttons and
its keybindings are modeled after Emacs, but it also offers optional
vi-like keybindings.

Notes:

  [1] Exact license still unclear since it's not mentioned on the
  website and I have no feedback neither from the #conkeror
  IRC-channel nor mailinglist yet. I've also skimmed through the
  source code and haven't found anything, but since the mozdev.org
  policy for hosted projects only allows projects under MPL or an
  OSI-approved license, it should not give any bad surpises
  here. :-)

  [2] It's implemented and installed as a Firefox extension, but using
  a wrapper script loading the appropriate chrome files, it should
  be able to install it as it would be a standalone browser (using
  all the Firefox preferences, though). Additionally, any user can
  choose to start conkeror instead of firefox when firefox is
  called. But I don't want to implement this as default. It also
  seems to really need firefox and not only xulrunner.



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

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Petter Reinholdtsen wrote:
> [Don Armstrong]
> > Well, once I wake up a bit, you'll be able to go:
> >
> > Package: foopkg
> > User: username
> > Usertags: fooblehtag,bartag
> >
> > [But it won't work for setting multiple users... to do that, you'll
> > have to use control.]
> 
> This is even better.  Is there a web page documenting this new
> feature?  I would like to point the debian-edu developers to it.

Documentation? What's that?

It'll show up on http://www.debian.org/Bugs/Reporting once wml gets
rebuilt.


Don Armstrong
 
-- 
The sheer ponderousness of the panel's opinion ... refutes its thesis
far more convincingly than anything I might say. The panel's labored
effort to smother the Second Amendment by sheer body weight has all
the grace of a sumo wrestler trying to kill a rattlesnake by sitting
on it--and is just as likely to succeed.
 -- Alex Kozinski in Silveira V Lockyer

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Bruce Sass]

On Sat October 21 2006 13:35, Darren Salt wrote:
> I demand that Hendrik Sattler may or may not have written...
> > 64bit kernels are not available in the i386 archive. That makes the
> > 64bit libs rather useless, doesn't it?
>
> No - you could be using a locally-built 64-bit kernel.

Perhaps i386 needs something along the lines of localepurge for 64bit 
stuff.


- Bruce


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

Re: Bug mass filling

[Manoj Srivastava]

On Fri, 20 Oct 2006 17:18:41 -0700, Steve Langasek <[EMAIL PROTECTED]> said: 

> On Fri, Oct 20, 2006 at 05:37:36PM -0500, Manoj Srivastava wrote:
>> > That's not correct. [serious, grave, and critical] are the
>> > "release critical" severities, though some release critical
>> > issues won't be fixed for any given release, due to either being
>> > not known about or understood (ie, not filed at all, or not given
>> > the appropriate severity or attention), or given a specific
>> > exemption by the release team ("etch-ignore").

>> So riddle me this: currently, policy states that violating a "must"
>> or "required" directive in policy is a serious bug; which seems to
>> fly in the face of the release process having appropriated the
>> "serious" severity.

>> Are we removing the policy that violations of policy requirements
>> are serious bugs?  Is there new guidance on what policy violation
>> bug severities ought to be?  Are such bugs to be filed under
>> "normal"? Or "important"?

>> My understanding, which seems to be flawed, was policy violations
>> were taken seriously (heh), and policy violation meant to be
>> ignored for a release were granted special dispensation (remained
>> serious, but were exempt).

>> If this is not the case, we should change the policy, and drop any
>> reference to bug severities for packages violating policy.
>> Personally, think that is not a good idea, since adherence to
>> technical policy seems to be the underpinning of the high quality
>> of implementation we always had, but perhaps my mileage has varied.

> When there are issues addressed in policy that are black-and-white
> where all violations of the policy requirement are definitely bugs,
> but not all such violations should be grounds for keeping a package
> out of a release, how do you suggest such rules should be handled in
> the normative language of policy, and how do you suggest that the
> related bugs be handled in the BTS?

Gee. Don't we already have something very like this? 

 These classifications are roughly equivalent to the bug severities
 _serious_ (for _must_ or _required_ directive violations), _minor_,
 _normal_ or _important_ (for _should_ or _recommended_ directive
 violations) and _wishlist_ (for _optional_ items).  [2]

All critical and grave bugs are release critical, and most
 serious bugs too. Any serious but which is non RC is tagged
 -ignore; and the ignore tag should only be set after
 consultation with the release managers.

> How should we distinguish this case from rules that are *generally*
> but not always an indication of a bug (policy's description of
> "should"), and from one-time exception grants by the release team
> (the current use of the "-ignore" tag)?

No one ever indicated that violations of a policy should
 directive is release critical, or even serious. Are you suggesting we
 should make _any_ policy violation the same?

Curently, violating a should policy directive means you get a
 "normal" severuty bug.

> The current handling sanctioned by the BTS admins seems an
> appropriate middle ground for distinguishing the cases that are most
> relevant to bug handling across releases.

It muddies up the nice, clean distinction that has always been
 in out technical policy: 

 a) MUST/REQUIRED violation: serious bug
If ignored
  a1) not RC
else
 a2) RC
 b) SHOULD violation
normal bug
 c) MAY/SUGGESTED violation
wishlist bug

manoj
-- 
If only you knew she loved you, you could face the uncertainty of
whether you love her.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Nikita V. Youshchenko]

> Am Samstag 21 Oktober 2006 11:49 schrieb Nikita V. Youshchenko:
>> Question is - does Debian i386 currently support running on 64-bit
>> binaries if hardware supports it?
> 
> _and_ if the kernel supports it.
> 
>> Linux blacky 2.6.18-1-k7 #1 SMP Fri Sep 29 17:06:47 UTC 2006 i686
>> GNU/Linux
> 
> -k7 is for Athlon without 64bit extensions.
> 64bit kernels are not available in the i386 archieve. That makes the 64bit
> libs rather useless, doesn't it?

Is it possible to make 64bit kernels available?


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Darren Salt]

I demand that Hendrik Sattler may or may not have written...

[snip]
> 64bit kernels are not available in the i386 archive. That makes the 64bit
> libs rather useless, doesn't it?

No - you could be using a locally-built 64-bit kernel.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government.WE'RE KILLING THE PLANET.

Fatal error in Reality (invalid parameter '-utopia')


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

Re: Question regarding maintainer email

[Marc Haber]

On Fri, 20 Oct 2006 17:16:52 +0200, Petter Reinholdtsen
<[EMAIL PROTECTED]> wrote:
>Yeah.  And if you get a lot of spam to the list, using the listadmin
>script make it a lot easier to process through the moderation
>requests.  One of the list I moderate get 200 spam a day, and I would
>never have been able to moderate it if it wasn't for the listadmin
>package.

Agreed. It would be even better if listadmin would be able to show a
list of messages instead of processing each message one after the
other.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Please upload NMU of tix package to close #360920

[Michael Hanke]

I forgot to mention the NMU in the changelog explicitely. I uploaded another 
package with a complete changelog entry.

Cheers,

Michael


On Sat, Oct 21, 2006 at 09:16:50PM +0200, Michael Hanke wrote:
> tags 360920 patch
> 
> thanks
> 
> 
> Hi,
> 
> I found out that the tix-dev does not install the essential tix.h. This
> is extremly inconvenient, if you need tix. There is a bugreport about this 
> that is
> almost 200 days old, without a response by the maintainer.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360920
> 
> I'm not sure why this bug has severity 'normal'. A significant part of
> the package is pretty useless without the header.
> 
> I fixed the bug and uploaded the NMU to mentors.d.n. Because this is
> already the third NMU in a row this message is send to debian-devel
> directly (maintainer is CC'ed).
> 
> I'd be glad if someone could upload the package (I'm not a DD). I have
> to admit that the fix is not the most beautiful. However, it is fairly
> simple and should work. Please see the attached diff.
> 
> And yes, the package is anything else than lintian clean!
> 
> The package is here:
> 
> http://mentors.debian.net/debian/pool/main/t/tix/tix_8.4.0-4.3.dsc
> 
> or 
> 
> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tix
> 
> 
> Thanks in advance,
> 
> 
> Michael
> 
> 
> 
> -- 
> GPG key:  1024D/3144BE0F Michael Hanke
> http://apsy.gse.uni-magdeburg.de/hanke
> ICQ: 48230050

> diff -rNu tix-8.4.0.old/debian/changelog tix-8.4.0/debian/changelog
> --- tix-8.4.0.old/debian/changelog2006-10-21 21:02:15.0 +0200
> +++ tix-8.4.0/debian/changelog2006-10-21 21:02:27.0 +0200
> @@ -1,3 +1,9 @@
> +tix (8.4.0-4.3) unstable; urgency=low
> +
> +  * Modified debian/rules to manually install missing tix.h (Closes: 
> #360920). 
> +
> + -- Michael Hanke <[EMAIL PROTECTED]>  Sat, 21 Oct 2006 20:57:25 +0200
> +
>  tix (8.4.0-4.2) unstable; urgency=low
>  
>* Non-maintainer upload.
> diff -rNu tix-8.4.0.old/debian/rules tix-8.4.0/debian/rules
> --- tix-8.4.0.old/debian/rules2006-10-21 21:02:15.0 +0200
> +++ tix-8.4.0/debian/rules2006-10-21 21:02:27.0 +0200
> @@ -108,7 +108,10 @@
>   pkglibdir=/usr/lib/tix$(tix_version) \
>   PKG_LIB_FILE=libTix$(tix_version).so.1 \
>  
> - # Move things around
> + : # install missing tix.h
> + cp $(CURDIR)/generic/tix.h $(d_dev)/usr/include
> +
> + : # Move things around
>  
>   mv $(d_run)/usr/lib/tix$(tix_version)/*.so* $(d_run)/usr/lib/
>   mv $(d_run)/usr/lib/tix$(tix_version)/*.a $(d_dev)/usr/lib/




-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


signature.asc
Description: Digital signature

Please upload NMU of tix package to close #360920

[Michael Hanke]

tags 360920 patch

thanks


Hi,

I found out that the tix-dev does not install the essential tix.h. This
is extremly inconvenient, if you need tix. There is a bugreport about this that 
is
almost 200 days old, without a response by the maintainer.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360920

I'm not sure why this bug has severity 'normal'. A significant part of
the package is pretty useless without the header.

I fixed the bug and uploaded the NMU to mentors.d.n. Because this is
already the third NMU in a row this message is send to debian-devel
directly (maintainer is CC'ed).

I'd be glad if someone could upload the package (I'm not a DD). I have
to admit that the fix is not the most beautiful. However, it is fairly
simple and should work. Please see the attached diff.

And yes, the package is anything else than lintian clean!

The package is here:

http://mentors.debian.net/debian/pool/main/t/tix/tix_8.4.0-4.3.dsc

or 

http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=tix


Thanks in advance,


Michael



-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050
diff -rNu tix-8.4.0.old/debian/changelog tix-8.4.0/debian/changelog
--- tix-8.4.0.old/debian/changelog  2006-10-21 21:02:15.0 +0200
+++ tix-8.4.0/debian/changelog  2006-10-21 21:02:27.0 +0200
@@ -1,3 +1,9 @@
+tix (8.4.0-4.3) unstable; urgency=low
+
+  * Modified debian/rules to manually install missing tix.h (Closes: #360920). 
+
+ -- Michael Hanke <[EMAIL PROTECTED]>  Sat, 21 Oct 2006 20:57:25 +0200
+
 tix (8.4.0-4.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -rNu tix-8.4.0.old/debian/rules tix-8.4.0/debian/rules
--- tix-8.4.0.old/debian/rules  2006-10-21 21:02:15.0 +0200
+++ tix-8.4.0/debian/rules  2006-10-21 21:02:27.0 +0200
@@ -108,7 +108,10 @@
pkglibdir=/usr/lib/tix$(tix_version) \
PKG_LIB_FILE=libTix$(tix_version).so.1 \
 
-   # Move things around
+   : # install missing tix.h
+   cp $(CURDIR)/generic/tix.h $(d_dev)/usr/include
+
+   : # Move things around
 
mv $(d_run)/usr/lib/tix$(tix_version)/*.so* $(d_run)/usr/lib/
mv $(d_run)/usr/lib/tix$(tix_version)/*.a $(d_dev)/usr/lib/


signature.asc
Description: Digital signature

Bug#394466: ITP: python-yadis -- Yadis service discovery library

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: python-yadis
  Version : 1.0.1
  Upstream Author : JanRain, Inc. <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : LGPL
  Programming Lang: Python
  Description : Yadis service discovery library

Yadis is a protocol for discovering services applicable to a URL.
This package provides a client implementation of the Yadis protocol.

Actually, Yadis is the OpenID/iNames/LID multiplexor at the moment.
More information may be found on http://yadis.org/

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Bug#394467: ITP: python-openid -- OpenID support for servers and consumers

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: python-openid
  Version : 1.1.0
  Upstream Author : JanRain, Inc. <[EMAIL PROTECTED]>
* URL : http://www.openidenabled.com/openid/libraries/python/
* License : LGPL
  Programming Lang: Python
  Description : OpenID support for servers and consumers

 Set of Python packages to support use of the OpenID decentralized
 identity system in your application, both server- and client-side.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Bits from the Debian GNU/kFreeBSD porters

[Petr Salinger]

Hello, Debian world!

This is a status update for the Debian GNU/FreeBSD port[1].
Compared to previous status mail [2], this port now consists
of two architectures: kfreebsd-i386 and kfreebsd-amd64.
Currently we focus mainly on kfreebsd-i386.

Status
--

 * We have uptodate toolchain and most of the core Debian packages
   are in good shape.

 * An unofficial buildd is up and running for both kfreebsd-i386 and
   kfreebsd-amd64, buildd logs for kfreebsd-i386 are available at [3].

 * There is a DD-accessible porting machine running kfreebsd-i386.
   http://io.debian.net/

 * For kfreebsd-i386, 80% packages have been built, 75% are up-to-date.
   See [4], [5].

 * We want to be in official archive, see #369797,
   http://wiki.debian.org/ArchiveQualification/kfreebsd-i386.


We need your help
-

  * as ftpmaster, could you please take a look at #369797.

  * as package maintainer, could you please look at BTS
whether there is a kfreebsd submission and integrate it.
In many cases, it is sufficient to (auto)update config.sub/config.guess
or use recent libtool. See [6].

  * as NMUer, please could you look at kfreebsd submission in BTS (in addition
to usual translations).

Of course, you can also verify whether your package builds [3]
and/or use porting machine. We would also appreciate hosting a shell server 
and/or donate hardware for kfreebsd-amd64.

Currently we are thinking about releasing etch based snapshot
as we have reasonable subset of etch packages [5].

The Debian GNU/kFreeBSD porters

--
[1] http://wiki.debian.org/Debian_GNU/kFreeBSD
[2] http://lists.debian.org/debian-devel-announce/2005/08/msg00013.html
[3] http://experimental.ftbfs.de/
[4] http://unstable.buildd.net/buildd/kfreebsd-i386_stats
http://unstable.buildd.net/buildd/kfreebsd-amd64_stats
[5] http://glibc-bsd.alioth.debian.org/NOTES
[6] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;[EMAIL 
PROTECTED];pri0=pending:pending,forwarded,pending-fixed,fixed;ttl0=Outstanding,Forwarded,Pending%20Upload,Fixed%20in%20NMU;pri1=pending%3dpending%2btag%3dwontfix,pending%3dpending%2btag%3dmoreinfo,pending%3dpending%2btag%3dpatch,pending%3dpending%2btag%3dconfirmed,pending%3dpending;ttl1=Will%20Not%20Fix,More%20information%20needed,Patch%20Available,Confirmed,Unclassified;ord1=2,3,4,1,0,5


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

Bug#394463: ITP: python-urljr -- Common interface to urllib2 and curl for making HTTP requests

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: python-urljr
  Version : 1.0.0
  Upstream Author : JanRain, Inc. <[EMAIL PROTECTED]>
* URL : http://www.openidenabled.com/openid/libraries/python/
* License : LGPL
  Programming Lang: Python
  Description : Common interface to urllib2 and curl for making HTTP 
requests

python-urljr contains the "fetchers" module, which provides a common
interface to urllib2 and curl for making HTTP requests.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-2-686
Locale: LANG=C, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)


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

Bug#394460: ITP: xenman -- A graphical Xen management tool

[Roland Stigge]

Package: wnpp
Severity: wishlist
Owner: Roland Stigge <[EMAIL PROTECTED]>

* Package name: xenman
  Version : 0.5
  Upstream Author : Haphazard <[EMAIL PROTECTED]>, Jd <[EMAIL PROTECTED]>, Yves 
Perrenoud <[EMAIL PROTECTED]>
* URL : http://xenman.sourceforge.net/
* License : GPL, LGPL
  Programming Lang: Python
  Description : A graphical Xen management tool

XenMan is a Xen management tool with a GTK based graphical interface
that allows for performing the standard set of domain operations
(start, stop, pause, kill, shutdown, reboot, snapshot, etc...). It
also attempts to simplify certain aspects such as the creation of
domains, as well as making the consoles available directly within the
tool's user interface.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)


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

NEW processing slowdown (Was: FAQ, Re: new mplayer)

[Petter Reinholdtsen]

[Tshepang Lekhonkhobe]
> I don't know if this is answered elswhere, but how come it is still
> stuck in NEW?

The speed of NEW processing have slowed down significantly this
autumn.  There used to be enough people working on it, but at the
moment there are too few doing it.  This summer, it was down to 22
packages, and now it is 132 packages.

I suspect something need to be done with the NEW process, as adding
more people seem to only improve the situation for a limited time.
Perhaps it could be optimized to make it less time consuming for those
processing it, or perhaps it need a complete redesign to avoid the
current bottleneck.  I'm not sure, as I only see it from the outside
through http://ftp-master.debian.org/new.html>.

Friendly,
-- 
Petter Reinholdtsen


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

Re: Bug mass filling

[Petter Reinholdtsen]

[Don Armstrong]
> Well, once I wake up a bit, you'll be able to go:
>
> Package: foopkg
> User: username
> Usertags: fooblehtag,bartag
>
> [But it won't work for setting multiple users... to do that, you'll
> have to use control.]

This is even better.  Is there a web page documenting this new
feature?  I would like to point the debian-edu developers to it.

Friendly,
-- 
Petter Reinholdtsen


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

Re: On including 64-bit libs in 32-bit packages (see #344104)

[Hendrik Sattler]

Am Samstag 21 Oktober 2006 11:49 schrieb Nikita V. Youshchenko:
> Question is - does Debian i386 currently support running on 64-bit binaries
> if hardware supports it?

_and_ if the kernel supports it.

> Linux blacky 2.6.18-1-k7 #1 SMP Fri Sep 29 17:06:47 UTC 2006 i686 GNU/Linux

-k7 is for Athlon without 64bit extensions.
64bit kernels are not available in the i386 archieve. That makes the 64bit 
libs rather useless, doesn't it?

HS


pgpZyZ0Vfswgr.pgp
Description: PGP signature

Re: Bug mass filling

[Amaya]

Anthony Towns wrote:
> Please hold off on filing them for a few days, so I can add
> usertag-on-submit support to debbugs, so that it should be possible to
> automatically track this stuff, and easily avoid filing duplicate bugs
> if they're not fixed the next time bugs get filed.

Thanks, AJ. That is just what I was about to ask for :)


-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Re: Bug mass filling

[Amaya]

Miriam Ruiz wrote:
> Why don't we all try to calm down and get less paranoid?

I hope there are big Finnish saunas in Edinburgh. 
I think we all need to gather for a hot sauna next DebConf.

We should change this "you can't flame people you have had sauna with"
to "you can't flame me until you've had sauna with me" :)

> Most of us are nice people with just strong feelings about their
> ideas, but I guess it might be nice for all of us to learn how to
> empathyse and respect other's ideas, and think for a moment that other
> people might also good reasons for them, as not everything is black or
> white.

What I do as an exercise in order to improve the skills you mention,
empathy, respect, the feel of pleasure from working with others, is to
work with the people I sponsor. 

They provide manpower and skills I lack, they fix bugs I have no time to
look at, while I learn from them as they learn from me. I make mistakes
they forgive me for, they make mistakes I can help them fix. It is
something I encourage you all to do. Take a sponsoree and be his/her
mentor. It's good for the karma.

-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

On including 64-bit libs in 32-bit packages (see #344104)

[Nikita V. Youshchenko]

Question is - does Debian i386 currently support running on 64-bit binaries 
if hardware supports it?

Just checked:

$ apt-get install libc6-dev-amd64
...
$ gcc -m64 -o hello hello.c
$ ./hello
bash: ./hello: cannot execute binary file
$ cat /proc/cpuinfo
...
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
...
$ uname -a
Linux blacky 2.6.18-1-k7 #1 SMP Fri Sep 29 17:06:47 UTC 2006 i686 GNU/Linux
$ apt-cache policy  linux-image-2.6.18-1-k7
linux-image-2.6.18-1-k7:
  Installed: 2.6.18-2
  Candidate: 2.6.18-2
  Version table:
 *** 2.6.18-2 0
600 http://blacky unstable/main Packages
100 /var/lib/dpkg/status

So current debian i386 setup does not support running 64-bit libraries.
If so, probably 64-bit libraries should not included in 32-bit packages.

Btw, if that technically possible, I'll prefer setup where 64-bit libraries 
will work (although the most of system will still be 32-bit)


pgp231XIdqEYh.pgp
Description: PGP signature

Re: Does anybody know where Janez Rabzelj Zappone is?

[Amaya]

Carlos Martín Nieto wrote:
>  I ask because he took (or was going to anyway) maintainership of the
> package blam, but this was about a month ago and no new version has
> been uploaded.

I am not so sure, he doesn't look like he intends to adopt blam:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387945
I think he just 

>  I sent him an e-mail a few days ago but he hasn't replied. There is
> already a package ready which fixes at least two of the RC bugs, and
> perhaps another or two as a side-effect.

Great job!

>  I'm not looking forward to hijacking a package, but with four RC bugs
>  and the release of etch closing in, I don't see another way to
>  include it in etch.

I'd say go ahead. We need to release etch with a working blam version.
He can always help you co-maintain if he is interested.

>  So, if anybody knows that he is working on it, please speak up,
> otherwise I will be requesting a sponsor for an updated blam package.

You just found your sponsor, email me in private.

-- 
  ·''`. If I can't dance to it, it's not my revolution
 : :' :-- Emma Goldman
 `. `'   Proudly running Debian GNU/Linux (unstable)
   `- www.amayita.com  www.malapecora.com  www.chicasduras.com


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

Re: FAQ, Re: new mplayer

[Tshepang Lekhonkhobe]

On 9/26/06, A Mennucc <[EMAIL PROTECTED]> wrote:

hi everybody

I just now notice the debate on mplayer going on;
so here are a few answers


[snip: mplayer is okay to go in]

I don't know if this is answered elswhere, but how come it is still
stuck in NEW?


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

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Andreas Barth wrote:
> * Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
> > On Sat, 21 Oct 2006, Christian Perrier wrote:
> > > > Please hold off on filing them for a few days, so I can add
> > > > usertag-on-submit support to debbugs, so that it should be possible to
> > >   ^^
> > > 
> > > *that* will be a great feature..:)
> > 
> > This should "in theory" be working now.
> > 
> > Usertag: fooblehtag
> > 
> > should set the fooblehtag of the user sending the mail.
> 
> How can I set usertags of another user (or rather roleaccount) during
> submission?

Well, once I wake up a bit, you'll be able to go:

Package: foopkg
User: username
Usertags: fooblehtag,bartag

[But it won't work for setting multiple users... to do that, you'll
have to use control.]


Don Armstrong

-- 
In all matters of government, the correct answer is usually: "Do
nothing"
 -- Robert Heinlein _Time Enough For Love_ p428

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Bug mass filling

[Andreas Barth]

* Don Armstrong ([EMAIL PROTECTED]) [061021 09:54]:
> On Sat, 21 Oct 2006, Christian Perrier wrote:
> > > Please hold off on filing them for a few days, so I can add
> > > usertag-on-submit support to debbugs, so that it should be possible to
> >   ^^
> > 
> > *that* will be a great feature..:)
> 
> This should "in theory" be working now.
> 
> Usertag: fooblehtag
> 
> should set the fooblehtag of the user sending the mail.

How can I set usertags of another user (or rather roleaccount) during
submission?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Bug mass filling

[Don Armstrong]

On Sat, 21 Oct 2006, Christian Perrier wrote:
> > Please hold off on filing them for a few days, so I can add
> > usertag-on-submit support to debbugs, so that it should be possible to
>   ^^
> 
> *that* will be a great feature..:)

This should "in theory" be working now.

Usertag: fooblehtag

should set the fooblehtag of the user sending the mail.


Don Armstrong

-- 
If a nation values anything more than freedom, it will lose its
freedom; and the irony of it is that if it is comfort or money it
values more, it will lose that, too.
 -- W. Somerset Maugham

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Javier Fernández-Sanguino Peña]

On Fri, Oct 20, 2006 at 07:10:20PM -0400, Kevin Mark wrote:
> Hi Javier,
> On Sat, Oct 21, 2006 at 12:05:58AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > 
> > I'm not sure if anybody else is seeing this but I have seen (just today) 28
> > spam messages sent to the BTS. I've received them because they were all sent
> 
> I've seen BTS spam before and ask the list admins about it.

I have seen it too, it's just that yesterday it blew out of proportion.

> Does BTS mail have identifiable header and/or body characteristics to
> determine what is legitimate? Does all mail to the bts come from: debian.org
> mailers, reportbugs or some identifable sources that would make
> legitimate email identifable?

Currently, anyone with a legitimate e-mail address can send a bug report
(properly formatted, so it's more difficult for SPAM to open bugs) to
[EMAIL PROTECTED] or append information to a bug (no formatting required, so 
it's
rather easy for SPAM to get there) by sending it to [EMAIL PROTECTED]

I'm more concerned by the fact that spam can close bugs, for reference read:
http://lists.debian.org/debian-devel/2002/05/msg00113.html
http://lists.debian.org/debian-devel/2004/03/msg00847.html
http://lists.debian.org/debian-devel/2005/07/msg01106.html

AFAIK, here's currently no technical measure in place (X-Header required,
whitelist of valid senders, GPG signature) that prevents spammers from
hitting [EMAIL PROTECTED], so when that happens it has to be delt with
manually (like it recently happened with [1], but there have been occassions
where it has been more aggresive)

Regards

Javier

[1] http://lists.debian.org/debian-policy/2005/09/msg00064.html


signature.asc
Description: Digital signature

Re: Is there a need for /usr/lib64/ on a pure i386?

[Goswin von Brederlow]

Stanislav Maslovski <[EMAIL PROTECTED]> writes:

> Hello d-dev,
>
> I noticed yesterday that after an upgrade I got a /usr/lib64 dir
> with some (not neded) stuff in it. I am not running any 64 bit arch.
>
> $ dpkg -S /usr/lib64 # says:
> libg2c0-dev, fakeroot, libgfortran1-dev: /usr/lib64
>
> I have found that there is a bug [1] on fakeroot reporting the same.
>
> The question is: will it become a common practice that packages for i386
> will include 64-bit libraries? After reading the reply of Clint Adams on [1]
> I have got such an impression. Please correct me if I am wrong.
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344104

If you have a 64bit cpu and are running a 64bit kernel then you can
run 64bit software on your system. If you combine this with using
fakeroot you suddenly need a 64bit libfakeroot.

The other case is compiling 64bit software. Even if you only have a
32bit system you can still build 64bit programms for use somewhere
else.

Usually 32bit and 64bit libraries are split up like libc6 and
libc6-amd64. In the case of fakeroot we are talking about 64KiB. That
certainly isn't enough to be split into a seperate package.

It looks like -dev packages aren't split between 32bit and 64bit. That
might be good or bad. But please leave fakeroot out of it. That
package is perfectly fine as is.

MfG
Goswin

PS: IIRC you even need a 64bit libfakeroot for dpkg-shlibs to work on
any 64bit library when building 32/64bit debs like glibc, gcc, ...


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

Re: Bug mass filling

[Christian Perrier]

> Please hold off on filing them for a few days, so I can add
> usertag-on-submit support to debbugs, so that it should be possible to
  ^^

*that* will be a great feature..:)




signature.asc
Description: Digital signature