Re: Sid is/was crazy

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> /var/cache/apt/archives/partial/yelp_2.10.0-3_i386.deb - open (30 
> Read-only file system) [IP: 204.152.191.7 80]
> debian:~# screen
> mkfifo /var/run/screen/S-root/5922.pts-0.debian failed

your /var is mounted read only mode because your kernel had an hardware IO 
error.

>Additional sense: Scsi parity error

this could be a failing device electronics, broken wiring, thermal or power
problems - less likely is a failing drive but also possible.

Backup your data as long as you can.

Gruss
Bernd


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

Re: Sid is/was crazy

[Carlos C Soto]

Hi Alejandro.

Looks like your ext3 partition has errors and the system remount it in 
readonly mode.
Not every problem get corrected by apt, I mean apt rocks but this is not 
a package problem.
Try to check your partition with fsck (man fsck, man fsck.ext3) maybe 
you need will to execute a livecd ( from man fsck.ext3: "...in  general 
it is not safe to run e2fsck on mounted filesystems...")


Maybe you want to enter some IRC Channel to get some quickly and in 
spanish answers.


Cheers
eclipxe

Alejandro Bonilla Beeche wrote:


Hi,

Every some hours my Debian Sid box goes wild and I can't do anything. 
Not even being root.


Is crazy. I can't even do apt-get update to try fixing this problem...

Err http://http.us.debian.org unstable/main xpdf-common 3.01-2
 Could not open file 
/var/cache/apt/archives/partial/xpdf-common_3.01-2_all.deb - open (30 
Read-only file system) [IP: 64.50.236.52 80]

Err http://http.us.debian.org unstable/main yelp 2.10.0-3
 Could not open file 
/var/cache/apt/archives/partial/yelp_2.10.0-3_i386.deb - open (30 
Read-only file system) [IP: 204.152.191.7 80]

39% [Waiting for headers]
debian:~# whoami
root
debian:~# screen
mkfifo /var/run/screen/S-root/5922.pts-0.debian failed

dmesg:

SCSI error : <0 0 0 0> return code = 0x802
sda: Current: sense key: Aborted Command
   Additional sense: Scsi parity error
end_request: I/O error, dev sda, sector 147753830
Buffer I/O error on device sda3, logical block 1572865
lost page write due to I/O error on sda3
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ata1: command 0x25 timeout, stat 0xd0 host_stat 0x21
ata1: status=0xd0 { Busy }
SCSI error : <0 0 0 0> return code = 0x802
sda: Current: sense key: Aborted Command
   Additional sense: Scsi parity error
end_request: I/O error, dev sda, sector 144346022
EXT3-fs error (device sda3): ext3_get_inode_loc: unable to read inode 
block - inode=571367, block=1146889

Remounting filesystem read-only
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ata1: command 0x25 timeout, stat 0x50 host_stat 0x21
EXT3-fs error (device sda3) in ext3_reserve_inode_write: IO failure


This like a 1 month old apt-get upgrade.

.Alejandro





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

Sid is/was crazy

[Alejandro Bonilla Beeche]

Hi,

Every some hours my Debian Sid box goes wild and I can't do anything. 
Not even being root.


Is crazy. I can't even do apt-get update to try fixing this problem...

Err http://http.us.debian.org unstable/main xpdf-common 3.01-2
 Could not open file 
/var/cache/apt/archives/partial/xpdf-common_3.01-2_all.deb - open (30 
Read-only file system) [IP: 64.50.236.52 80]

Err http://http.us.debian.org unstable/main yelp 2.10.0-3
 Could not open file 
/var/cache/apt/archives/partial/yelp_2.10.0-3_i386.deb - open (30 
Read-only file system) [IP: 204.152.191.7 80]

39% [Waiting for headers]
debian:~# whoami
root
debian:~# screen
mkfifo /var/run/screen/S-root/5922.pts-0.debian failed

dmesg:

SCSI error : <0 0 0 0> return code = 0x802
sda: Current: sense key: Aborted Command
   Additional sense: Scsi parity error
end_request: I/O error, dev sda, sector 147753830
Buffer I/O error on device sda3, logical block 1572865
lost page write due to I/O error on sda3
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ata1: command 0x25 timeout, stat 0xd0 host_stat 0x21
ata1: status=0xd0 { Busy }
SCSI error : <0 0 0 0> return code = 0x802
sda: Current: sense key: Aborted Command
   Additional sense: Scsi parity error
end_request: I/O error, dev sda, sector 144346022
EXT3-fs error (device sda3): ext3_get_inode_loc: unable to read inode 
block - inode=571367, block=1146889

Remounting filesystem read-only
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ATA: abnormal status 0xD0 on port 0xEC07
ata1: command 0x25 timeout, stat 0x50 host_stat 0x21
EXT3-fs error (device sda3) in ext3_reserve_inode_write: IO failure


This like a 1 month old apt-get upgrade.

.Alejandro


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

Re: Bits from the release team: the plans for etch

[Thomas Bushnell BSG]

Frank Küster <[EMAIL PROTECTED]> writes:

>>> Can't the patch be posted to the BTS and NMUed after two days if
>>> there's no response (in general)?
>>
>> Yeah, but golly, sometimes there is no patch because the patch is
>> blindingly obvious.
>
> No, no, no.  Please not.  There's always a patch, and if it's only the
> changelog entry.

You misunderstand me, because I was unclear.

Of course I always put a patch in when I NMU.  But I don't necessarily
bother preparing a patch until it's time to actually NMU, when
preparing the patch isn't actually a help to the maintainer.

> It is extremely annoying if the first mail you find in your "package
> foo" mail folder is the message by katie (or who is it?) that a bug you
> didn't fix for one or the other reason has been fixed in an upload, but
> you never heard that anybody intended to NMU, what they did, and maybe
> why.

This doesn't happen in the scenario in question; we are talking about
where the maintainer has been asked "what do you plan to do about bug
NNN" and gotten no reply.  By definition, the uploadcan't be the first
mail you find in this case; it's at least the third.

Thomas

Bug#334641: ITP: metaplanet -- Web-based feed aggregator written in PHP

[Fernando J . Rodríguez]

Package: wnpp
Severity: wishlist
Owner: "Fernando J. Rodríguez" <[EMAIL PROTECTED]>

* Package name: metaplanet
  Version : 0.3
  Upstream Author : Oscar Cubo Medina <[EMAIL PROTECTED]> and Ramóons Vivanco 
<[EMAIL PROTECTED]>
* URL : http://laurel.datsi.fi.upm.es/metaplanet/
* License : GPL2
  Description : Web-based feed aggregator written in PHP

Metaplanet is a feed agregrator that shows the news of multiple sources
in a unified web page. The main objetive is to serve web pages as fast
as posible with a minimum load on the server.
.
It features a calendar, faces support with size control, caches, themes,
internationalization and easy customization.
.
Metaplanet: supports aggregation of feeds in  RSS1 (RDF), RSS2,
Atom 0.3, OPML and FOAFROLL formats, outputting HTML as well as
any of the aforementioned formats.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-k7
Locale: LANG=es_AR, LC_CTYPE=es_AR (charmap=ISO-8859-1)


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

Bug#334605: ITP: acpidump -- utility to dump system's ACPI tables to an ASCII file

[Mattia Dongili]

Package: wnpp
Severity: wishlist
Owner: Mattia Dongili <[EMAIL PROTECTED]>


* Package name: acpidump
  Version : 20050926
  Upstream Author : Alexey Starikovskiy
* URL : 
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
* License : GPLv2
  Description : utility to dump system's ACPI tables to an ASCII file

This package contains a small collection of utilities ACPI system
tables:
 * acpidump: to dump tables
 * acpixtract: to convert ASCII acpidump output to raw binary
 * acpitbl: to dump the table header or contents of a raw ACPI table

Note: Upstream package is called pmtools.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc4-mm1-1
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
-- 
mattia
:wq!


signature.asc
Description: Digital signature

Re: udev and Logitech mouse applet

[Christopher Martin]

On October 18, 2005 03:30, Marco d'Itri wrote:
> OK, as it turns out I was half wrong: /proc/bus/ is not syncronous, so
> scripts still need to wait (they may use the wait_for_file function from
> /lib/hotplug/hotplug.functions). OTOH, RUN is still the correct keyword
> to use, because PROGRAM has different semantics (and you must always use
> += unless you know better).

OK.

> > a modular kernel? I did notice that a homebrew everything-built-in
> > kernel did not suffer from this problem. I just took it for granted
> > that the udev/hotplug maintainer would be testing against a stock
> > Debian kernel, or at least something similarly modularized.
>
> I need newer kernels before a debian package is available, and anyway I
> will not use debian kernels again as long as they will break drivers
> by removing uploadable firmwares.

Needing to test newer kernels is quite understandable, but you really ought 
to at least test udev with a Debian kernel, just to make sure that module 
loading is functioning properly.

> Because the rule matches on many events, among them BUS=="usb".
> The correct rule to change the /dev/bus/usb/ device permissions would
> be:
>
> SUBSYSTEM=="usb_device", SYSFS{idProduct}=="0039",
> SYSFS{idVendor}=="045e", GROUP="plugdev"
>
> (660 is the default.)

That information will be very helpful when /dev/bus/usb arrives, for a 
number of developers I'm sure - thanks.

Cheers,
Christopher Martin


pgpHEvMnoRoSP.pgp
Description: PGP signature

Re: Non-x86 architectures becomes more popular in Debian...

[Martijn van Oosterhout]

> And for those of you interested in the architecture distribution, here
> are the numbers and percentages:

I think popcon is a really neat project. I do look every now and then
to see when the "unknown" line crosses the "amd64" line :) It's
getting close.

Keep up the good work,

Re: gpl vs openssl again

[Hendrik Sattler]

sean finney wrote:

> in the long run, i think it would be preferable to have this package
> have support for gnutls as an alternative to openssl.  however, i don't
> even know where to start on this.  does anyone here have some notes
> or links handy where i could start for porting the few ssl-using
> programs in nagios-plugins to use gnutls?

Take a look at:
http://www.gnu.org/software/gnutls/manual/html_node/Compatibility-with-the-OpenSSL-library.html

So replacing some includes may work. The documentation is pretty good with 
lots of example, very unlike the OpenSSL documentation.

HS

-- 
Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de
oder über pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org

Re: buzz/rex binaries/install media?

[Matej Vela]

Adrian von Bidder <[EMAIL PROTECTED]> writes:

> (Yes, I thought about sending this to -curiosa instead... :-)
>
> For research/fun/..., I want to install historical versions of Debian.  Does 
> anybody have install media of rex and buzz?  I guess it is possible to 
> create packages by starting at bo and compiling the older binaries, but I 
> don't know how easy it would be to recreate the installer disks...

See 
for buzz disks.  I'm sure rex is somewhere around as well.

Regards,

Matej


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

buzz/rex binaries/install media?

[Adrian von Bidder]

Yo!

(Yes, I thought about sending this to -curiosa instead... :-)

For research/fun/..., I want to install historical versions of Debian.  Does 
anybody have install media of rex and buzz?  I guess it is possible to 
create packages by starting at bo and compiling the older binaries, but I 
don't know how easy it would be to recreate the installer disks...

cheers
-- vbi

-- 
Elephant, n.:
A mouse built to government specifications.


pgp1RDBDC0CP7.pgp
Description: PGP signature

Bug#334530: ITP: libcatalyst-engine-apache-perl -- Base class for Apache 1.99x and 2.x Catalyst engines

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name : libcatalyst-engine-apache-perl
  Version  : 0.99
  Upstream Authors : Sebastian Riedel, <[EMAIL PROTECTED]>, 
 Christian Hansen, <[EMAIL PROTECTED]>, 
 Andy Grundman, <[EMAIL PROTECTED]>
* URL  : http://www.example.org/
* License  : (perl: Artistic/GPL)
  Description  : Base class for Apache 1.99x and 2.x Catalyst engines

 Catalyst is an elegant web application framework, extremely flexible yet
 extremely simple. It's similar to Ruby on Rails, Spring (Java) and Maypole,
 upon which it was originally based.
 .
 Catalyst follows the Model-View-Controller (MVC) design pattern, allowing you
 to easily separate concerns, like content, presentation, and flow control,
 into separate modules. This separation allows you to modify code that handles
 one concern without affecting code that handles the others. Catalyst promotes
 the re-use of existing Perl modules that already handle common web application
 concerns well.
 .
 This is a base class for Apache 1.99x and 2.x Engines.
   

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: Finding out in postinst whether some other package is configured

[Frank Küster]

Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>>
>>> Also how would a package inset such a Post-Invoke line into the
>>> conffig? Modifying the conffile would be a policy violation.
>>
>> The package that provides the hook to run provides the config entry; the
>> packages that need to run the hook touch a file in /var/ or
>> append a line to such a file.
>
> That means that every such case has to reinvent the wheel.
>
> Also you still haven't gotten the hook into the Post-Invoke apt
> option.

I don't remember how zope does it, but apparently it has found a way.
Probably it just drops a file into apt/conf.d, not caring about other
files specifying a Post-Invoke option (which works because there are
none...) 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Sid Upgrade, gstreamer0.8-oss (0.8.11-1.1)

[Christoph Berg]

Re: Alejandro Bonilla in <[EMAIL PROTECTED]>
> I was upgrading Sid and I saw this error message. I dunno if one goes to BTS
> or just here to report this. I hope it can be seen by someone who takes care
> of this package.
> 
> Setting up gstreamer0.8-oss (0.8.11-1.1) ...

To the BTS.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Sid Upgrade, gstreamer0.8-oss (0.8.11-1.1)

[Alejandro Bonilla]

Hi,

I was upgrading Sid and I saw this error message. I dunno if one goes to BTS
or just here to report this. I hope it can be seen by someone who takes care
of this package.

Setting up gstreamer0.8-oss (0.8.11-1.1) ...
OIL: ERROR liboiltest.c 309: oil_test_check_impl(): function
fbCompositeSolid_nxmmx in class composite_over_argb_const_src failed check
(1.67772e+07 > 100) outside=0

.Alejandro

--
Open WebMail Project (http://openwebmail.org)


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

Re: Finding out in postinst whether some other package is configured

[Goswin von Brederlow]

Frank Küster <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Also how would a package inset such a Post-Invoke line into the
>> conffig? Modifying the conffile would be a policy violation.
>
> The package that provides the hook to run provides the config entry; the
> packages that need to run the hook touch a file in /var/ or
> append a line to such a file.

That means that every such case has to reinvent the wheel.

Also you still haven't gotten the hook into the Post-Invoke apt
option.

>>> The big problem with that is that if such a command ever fails, how does
>>> the package system know which package caused the error?  It could be the
>>> one that first registered the call, but also an other package that would
>>> have added it to the journal if it hadn't been there yet.
>>
>> Probably all of them instead of just one.
>>
>> I don't see this as a big problem. Currently if one of the packages
>> adds broken files causing the update script to fail on average half
>> the packages will be broken (everything after the broken one).
>>
>> So having them all set to failed is just twice as bad from a statistic
>> point of view and doesn't create any extra work.
>
> You forget the extra work of the user (and the admin of the wrongly
> blamed package) to find out which package is responsible.  With the
> current setup, you just need to look at dpkg's output and check which
> package was first to fail.

Ok. If the error message sucks and doesn't reveal the culprit then you
have a point.

> Regards, Frank

MfG
Goswin


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

Re: gpl vs openssl again

[Paul TBBle Hampson]

On Tue, Oct 18, 2005 at 11:56:15AM +0200, Olaf van der Spek wrote:
> On 10/18/05, sean finney <[EMAIL PROTECTED]> wrote:
>> [1] please don't file an rc bug against my package for my having mentioned
>>this... i've recently adopted it and would like to see the 30 some odd
>>bugfixes make it into testing.

> Isn't it possible to tell the BTS the RC bug also applies to the
> version already in testing such that it doesn't prevent new versions
> that didn't fix the RC bug yet from reaching testing?

Not automatically, as I understand it. You either need to inform
-release that the bug needs ignoring for testing propagation, or wait
for full BTS version support to be implemented in britney, at which
point the dist-tags in the BTS become informative, and auto-generatable.

(I could be wrong, but I'm -pretty sure- that was how it was explained
to me)

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpl26rB7hqnV.pgp
Description: PGP signature

Re: When is it acceptable to revoke my gpg key?

[Christoph Berg]

Re: Roberto C. Sanchez in <[EMAIL PROTECTED]>
> Thanks for the pointer.  I was a bit confused since my QA page shows my
> key ID on it.

DDPO (aka developer.php) doesn't do that anymore. The code had been
broken for some time, and was disabled several weeks ago. The gpg
keyid was only informational anyway (and never really worked,
unfortunately).

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: When is it acceptable to revoke my gpg key?

[Roberto C. Sanchez]

On Tue, Oct 18, 2005 at 01:17:54PM +0200, Christoph Berg wrote:
> Re: Roberto C. Sanchez in <[EMAIL PROTECTED]>
> > I recently generated a new gpg key.  I was planning on revoking my old
> > key, however all of my packages were uploaded with signatures from my
> > old key.  Do I need to prepare new uploads with the new key?  Since I am
> > not too far into the NM process so far, my key is not in the Debian
> > keyring yet, so I am not concerned about that.  Thanks for any pointers.
> 
> As you are not a DD, your packages carry your sponsor's signatures in
> the archive. Even for DDs, no new uploads are necessary.
> 

Thanks for the pointer.  I was a bit confused since my QA page shows my
key ID on it.

-Roberto
-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


pgpQdIWSLOCAN.pgp
Description: PGP signature

Re: NMU policies for etch

[Frank Küster]

Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

We should really document the result of this discussion in the
developers' reference, which currently says:

,
| NMUs which fix important, serious or higher severity bugs are
| encouraged and accepted.
`

This I always interpreted as "NMUs which fix normal, minor or wishlist
bugs (only?) are discouraged and widely not accepted".

> On Tue, 18 Oct 2005, Frank Küster wrote:
>> Shouldn't NMU's without the maintainers approval be restricted to RC and
>> maybe important bugs?
>
> No, unless you add some sort of timeframe.  MIA or otherwise absent
> maintainers are the usual reason why one needs NMUs.


If a maintainer is "otherwise" absent, he usually sends a mail to
-private which says "NMU as needed", and it's up to you to balance the
impact of the fix with the time of vacation.

If a maintainer is MIA, the package should be orphaned and/or the
maintainer set to QA.  Until this has happened, we might have to relax
the NMU policy on that package.  However, as always this should be made
transparent:  There should be notes to the most interesting bugs (or on
the bug or qa page of the package) that the people interested in the bug
suspect the maintainer to be MIA.  This way, everybody can see how long
it has been noticed that the package is badly maintained, and know
better what timeframe is appropriate for an NMU.

Furthermore, please note that the developers' reference recommends to

,
| Follow what happens, you're responsible for any bug that you
| introduced with your NMU. You should probably use The Package Tracking
| System, Section 4.10 (PTS) to stay informed of the state of the
| package after your NMU.
`

Which means that you'll get more and more mails if you NMU many
packages, and that you should consider taking over a package that you
NMUed more than once...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

adept for Debian?

[Christoph Haas]

Hi...

A coworker just showed me his Ubuntu/Breezy installation featuring their
package management tool "adept" [1]. It looks pretty nifty. Are there plans
already to offer the same package in Debian? It's not listed in the wnpp
yet. I'm just curious if anyone has talked to Ubuntu maintainers about
making it available in Debian.

 Christoph

[1] http://web.ekhis.org/adept.html
-- 
~
~
~
".signature" [Modified] 3 lines --100%--3,41 All


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

Re: NMU policies for etch

[Henrique de Moraes Holschuh]

On Tue, 18 Oct 2005, Frank Küster wrote:
> Shouldn't NMU's without the maintainers approval be restricted to RC and
> maybe important bugs?

No, unless you add some sort of timeframe.  MIA or otherwise absent
maintainers are the usual reason why one needs NMUs.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: NMU policies for etch [Was: Re: Bits from the release team: the plans for etch]

[Daniel Ruoso]

Em Ter, 2005-10-18 às 01:03 -0700, Steve Langasek escreveu:
> I think a good balance would be something like:

What if all NMUs are delayed for N days, but if maintainer agrees the
NMU skips the delay...

daniel


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

Re: Bits from the release team: the plans for etch

[sean finney]

On Tue, Oct 18, 2005 at 01:12:49PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Tue, Oct 18, 2005 at 08:59:01AM +0100, Colin Watson wrote:
> > On Mon, Oct 17, 2005 at 02:56:57PM -0700, Thomas Bushnell BSG wrote:
> > > Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
> > > > Didn't there used to be a delayed queue for NMUs to go into so that the
> > > > maintainer has time to nix it if neccessary? ^_^
> > > 
> > > Sure, but at the moment, I only know one way to use dupload since the
> > > upload queues were changed.
> > 
> > This .dupload.conf fragment has been working for me for some time:
> 
> IIRC I updated dupload through a NMU a while back to add the new DELAYED
> queue in the stock dupload configuration files.

yes, as did i.  as it's still an NMU in progress, i'll be interested to
see if it eventually makes it to ftp-master :)  it is moving from
$n-delayed to ${n-1}-delayed though.

fwiw: i believe the cmdline i used was:

dput -e 7 gluck_delayed foo.changes



sean


-- 


signature.asc
Description: Digital signature

Re: Query about LmBench

[Christoph Berg]

Re: animesh bhowmick in <[EMAIL PROTECTED]>
> I found a download for MIPS. Then I saw it is having a
> .deb extension. How does one uncompress this?

1) Don't cross-post.
2) Install Debian. Read the installation notes.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: When is it acceptable to revoke my gpg key?

[Christoph Berg]

Re: Roberto C. Sanchez in <[EMAIL PROTECTED]>
> I recently generated a new gpg key.  I was planning on revoking my old
> key, however all of my packages were uploaded with signatures from my
> old key.  Do I need to prepare new uploads with the new key?  Since I am
> not too far into the NM process so far, my key is not in the Debian
> keyring yet, so I am not concerned about that.  Thanks for any pointers.

As you are not a DD, your packages carry your sponsor's signatures in
the archive. Even for DDs, no new uploads are necessary.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Bits from the release team: the plans for etch

[Javier Fernández-Sanguino Peña]

On Tue, Oct 18, 2005 at 08:59:01AM +0100, Colin Watson wrote:
> On Mon, Oct 17, 2005 at 02:56:57PM -0700, Thomas Bushnell BSG wrote:
> > Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
> > > Didn't there used to be a delayed queue for NMUs to go into so that the
> > > maintainer has time to nix it if neccessary? ^_^
> > 
> > Sure, but at the moment, I only know one way to use dupload since the
> > upload queues were changed.
> 
> This .dupload.conf fragment has been working for me for some time:

IIRC I updated dupload through a NMU a while back to add the new DELAYED
queue in the stock dupload configuration files.

Regards

Javier


signature.asc
Description: Digital signature

Re: a few tips on proper use of version tracking in the Debian BTS

[Christian Mack]

Hi Joey

Joey Hess wrote:
> In the process of my work on the testing security team, I've noticed
> that many developers still seem to be unfamiliar with how to use the new
> version tracking features[1] of the Debian BTS. 
< ... >
> I thought I'd conclude with an example of how to do it right, and wrong.
>   right: http://bugs.debuan.org/329839
< cut >
s/debuan/debian/  ;-)

I think this will take some time to spread among all DD's and other Developers.
But it's always a good thing to mention the consequences and show the benefit!

Thanks
Christian


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

Re: Non-x86 architectures becomes more popular in Debian...

[Gustavo Franco]

On 10/17/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> (...)
>
> > but is there anyone in the project with academic background about
> > this subject ?
>
> None of the current popcon maintainers have statistical background, as
> far as I know.
>
> We were in touch with someone interested in using the data set to make
> a recommender system for debian packages this summer, but nothing came
> out of this yet.  I believe it would be a nice feature to have,
> allowing admins to get reports about packages they might find
> interesting based on their current set of installed packages.

It sounds cool. FYI, i've used popcon data in a small script that aims
to be a "apt-cache search" replacement  - it can retrieve debtags data
too and order the results "by popcon", do you see? It wasn't a blocker
but it would be cool if popcon data was available in more script
friendly formats.

--
Gustavo Franco

Bug#334489: ITP: flamerobin -- graphical database administration tool for Firebird DBMS

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <[EMAIL PROTECTED]>

* Package name: flamerobin
  Version : 0.4.0
  Upstream Author : flamerobin (IDPL):
Barbara Del Vecchio
Gregory Sapunkov <[EMAIL PROTECTED]>
Michael Hieke <[EMAIL PROTECTED]>
Milan Babuskov <[EMAIL PROTECTED]>
Nando Dessena <[EMAIL PROTECTED]>
IBPP (MPL)
T.I.P. Group S.A. 
* URL : http://www.flamerobin.org/
* License : IDPL 1.0, IBPP lib is licensed under MPL 1.0
  Description : graphical database administration tool for Firebird DBMS

FlameRobin is a graphical database administration tool for Firebird
database management system.
.
Its goals are:
  - to be lightweight (small footprint, fast execution)
  - cross-platform (Linux, Windows for start, others planned too)
  - dependent only on other open source software
.
You need to setup firebird server on local or remote machine before
using FlameRobin. See packages firebird2-server-super and
firebird2-server-classic.


A package is basically ready at
ftp://ftp.logos-bg.net/debian-addons-bg/dists/sid/flamerobin/


--
dam
-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13+reiser4+dam.1
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)


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

Re: gpl vs openssl again

[Olaf van der Spek]

On 10/18/05, sean finney <[EMAIL PROTECTED]> wrote:
> [1] please don't file an rc bug against my package for my having mentioned
>this... i've recently adopted it and would like to see the 30 some odd
>bugfixes make it into testing.

Isn't it possible to tell the BTS the RC bug also applies to the
version already in testing such that it doesn't prevent new versions
that didn't fix the RC bug yet from reaching testing?

gpl vs openssl again

[sean finney]

hey -devel,

the zombie of gpl vs. openssl has once again arisen from the grave,
this time, in one of the packages that i maintain (nagios-plugins).
as i'm on the upstream development team as well, i've already clarified
with the other developers there that this is an omission, and that
we'll either reword the copyright with an addendum or otherwise remedy
things for the short term[1].  fortunately there's no api or shared
library exported by nagios-plugins, so it doesn't affect any other
packages.

in the long run, i think it would be preferable to have this package
have support for gnutls as an alternative to openssl.  however, i don't
even know where to start on this.  does anyone here have some notes
or links handy where i could start for porting the few ssl-using
programs in nagios-plugins to use gnutls?  any volunteers to help
out?  if so (and it would be very much appreciated) contact me on
or off-list and i'll show you where the "offending" code is.


sean

[1] please don't file an rc bug against my package for my having mentioned
this... i've recently adopted it and would like to see the 30 some odd
bugfixes make it into testing.
-- 


signature.asc
Description: Digital signature

Re: NMU policies for etch

[Frank Küster]

Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:

> [Olaf van der Spek]
>> If there's no approval, shouldn't 'that' be fixed also?
>
> Depends on the form of the lack of approval.  If there is no reply,
> the MIA process should be started, and if there is a NACK, the NMU
> should not go throught without further discussion.  But one should not
> have to waint for the MIA process to complete before doing NMUs to fix
> bugs in packages without a maintainer with time to follow up on his
> packages.

I agree in general; however I don't think it is appropriate to start the
MIA process (and will probably "fail") just because a maintainer didn't
answer to some "normal" bug with a patch.  People have very different
ways to do their Debian work.  Myself, I'm a communicator, and if you
don't receive any reply after a couple of days you can consider me on
vacation, or MIA.  

Others stay silent, but do their work, and after one or a couple of
weeks there's an upload which fixes your bug, among others.  I think we
should respect these people's way to do their work, and not interfere
with NMUs just because we think we shouldn't release with that bug.

Things are maybe different if it's only a couple of days until the
freeze (at least in the sense that under these circumstances, people are
"oblidged to communicate").  Sarge had of course the problem that for
at least three months the freeze was essentially scheduled for "next
week", and eight more where it was scheduled "real soon now".  But that
won't happen again, hopefully.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

New locale si_LK

[Anuradha Ratnaweera]

Hi all,

The locale si_LK was recently added to glibc (after a long stay in the
Bugzilla).  Please consider including it in the Debain glibc as it
will take some time before it will appear in mainstream glibc.  Thanks
in advance.

http://sourceware.org/bugzilla/show_bug.cgi?id=367

Anuradha

--
http://anuradha-ratnaweera.blogspot.com
http://www.linux.lk/~anuradha/

Re: NMU policies for etch

[Petter Reinholdtsen]

[Olaf van der Spek]
> If there's no approval, shouldn't 'that' be fixed also?

Depends on the form of the lack of approval.  If there is no reply,
the MIA process should be started, and if there is a NACK, the NMU
should not go throught without further discussion.  But one should not
have to waint for the MIA process to complete before doing NMUs to fix
bugs in packages without a maintainer with time to follow up on his
packages.


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

Re: NMU policies for etch

[Olaf van der Spek]

On 10/18/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Frank Küster]
> > Shouldn't NMU's without the maintainers approval be restricted to RC
> > and maybe important bugs?
>
> Well, assuming we want as many bugs as possible fixed before the
> release, and not only RC bugs, I believe NMUs should be possible for
> all kinds of bugs.
>
> With maintainer approval if possible. :)

If there's no approval, shouldn't 'that' be fixed also?

Re: NMU policies for etch

[Petter Reinholdtsen]

[Frank Küster]
> Shouldn't NMU's without the maintainers approval be restricted to RC
> and maybe important bugs?

Well, assuming we want as many bugs as possible fixed before the
release, and not only RC bugs, I believe NMUs should be possible for
all kinds of bugs.

With maintainer approval if possible. :)


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

Re: NMU policies for etch

[Frank Küster]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> I think a good balance would be something like:
>
> - send mail to the bug with a full diff *before* uploading your package to
>   incoming; two minutes before, two hours before, two days before, it
>   doesn't matter

And make sure that the mail has actually left your system... (real life
experience). 

> - don't NMU for feature requests (i.e., wishlist bugs) without the
>   maintainer's prior approval

Shouldn't NMU's without the maintainers approval be restricted to RC and
maybe important bugs?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

NMU policies for etch [Was: Re: Bits from the release team: the plans for etch]

[Steve Langasek]

On Mon, Oct 17, 2005 at 10:33:04AM +0200, Simon Richter wrote:

> Steve Langasek wrote:

> >It's easy to understand why people are opposed to too-frequent NMUs.  They
> >don't want to be seen as bad maintainers for having too many NMUs on their
> >packages; they worry about new bugs being introduced in the process; they
> >worry about sloppy fixes hiding bugs and preventing proper fixes from 
> >taking
> >place.

> My personal experience with NMUs has been pretty bad. In two cases, I 
> needed to add cleanup code in the postinst to sort out the mess, and in 
> one case the package turned Debian native. One "fixed" a problem where 
> the optimized assembler code in the upstream package wasn't used (MMX 
> assembler is bad, mmmkay?) and broke all other architectures at the same 
> time by unconditionally enabling it.

Hmm, I'm sorry to hear that.

Did you report these problems to the ftpmasters at the time?  They have in
the past restricted developers' upload rights as a result of inappropriate
NMUs.  Did you bring these problems up for discussion in public?

Unfortunately, when such problems are kept quiet, it makes it harder to
judge whether the NMU policies are working as advertised.

Were these problem NMUs done in accordance with the NMU policy at the time?
I'm not sure how much we should let the rules be influenced by people who
aren't *following* the rules.  Of course, there's an advantage to keeping
the rules simple, to improve the odds that everyone will be able to keep
track of them as well.  "Don't NMU unless you know what you're doing" is
actually a fairly complicated rule to follow.  "Don't NMU unless the patch
is in the BTS first" is a much simpler one.  "Don't NMU without consent of
the maintainer", "don't NMU unless the patch has been in the BTS for
three days", and "don't make any changes in an NMU that don't directly fix a
release-critical bug" are also *simple* rules, but they also make it harder
for people who *do* know what they're doing to get things done.

From what I've seen, I think our experience with sarge shows pretty
consistently that when you eliminate the red tape for NMUs, most people
doing NMUs do know what they're doing, and a lot of good work gets done.
So I definitely feel that whatever rules we adopt for etch should continue
to make it easy for good NMUers to upload good NMUs.

I think a good balance would be something like:

- send mail to the bug with a full diff *before* uploading your package to
  incoming; two minutes before, two hours before, two days before, it
  doesn't matter
- don't make any changes in an NMU that don't correspond to pre-existing
  reports in the BTS
- don't NMU for feature requests (i.e., wishlist bugs) without the
  maintainer's prior approval
- don't upload changes that you don't understand
- don't race maintainers to their own bugs; urgent uploads are sometimes
  necessary, but in most cases you should give maintainers a week to deal
  with the bug themselves.  Also see above about sending diffs to the BTS
  *before* uploading.

This seems to catch corner cases like turning on MMX assembler on all
arches; the attentive maintainer notices in less than a week that the bug
filed asking for MMX is wrong/unfixable and demotes it to wishlist with a
comment, and the responsible NMUer doesn't touch the wishlist bug.  I don't
know whether it takes care of NMUs screwed up badly enough to require
postinst fixes, or if there are other corner cases not addressed.  Do you
have thoughts on that?

> What would be Nice To Have(tm) would be a free-form text field on db.d.o 
> where I could state my wishes about NMUs on my packages.

Which then becomes a *very* complex rule that prospective NMUers have to
follow... :/  Is this kind of thing actually necessary if we are able to
come up with better project-wide NMU policies?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bits from the release team: the plans for etch

[Colin Watson]

On Mon, Oct 17, 2005 at 02:56:57PM -0700, Thomas Bushnell BSG wrote:
> Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
> > Didn't there used to be a delayed queue for NMUs to go into so that the
> > maintainer has time to nix it if neccessary? ^_^
> 
> Sure, but at the moment, I only know one way to use dupload since the
> upload queues were changed.

This .dupload.conf fragment has been working for me for some time:

if (exists $ENV{DEB_NMU_DELAY}) {
$delayed = "/DELAYED/$ENV{DEB_NMU_DELAY}-day";
}

# Tollef Fog Heen's DELAYED queue
$cfg{'tfheen-delayed'} = {
fqdn => "gluck.debian.org",
login => $ENV{DEBUSER} || getlogin() || $ENV{USER} || $ENV{LOGNAME},
incoming => "~tfheen$delayed",
dinstall_runs => 1,
method => "scpb",
};

Then 'DEB_NMU_DELAY=3 dupload --to tfheen-delayed foo.changes' for a
3-day delay.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


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

Re: Bits from the release team: the plans for etch

[Frank Küster]

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> Olaf van der Spek <[EMAIL PROTECTED]> writes:
>
>> On 10/17/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>>> Simon Richter <[EMAIL PROTECTED]> writes:
>>>
>>> > That is why I ask that before an NMU, someone should show me the patch,
>>> > and if I reply "I don't have time right now, okay to NMU that if you
>>> > like" then it's fine (and in fact it is going to be the answer you will
>>> > hear most from me ATM).
>>>
>>> What if you don't reply at all?  That's the problem in my experience.
>>> Not you particularly, of course; but I rarely get told "no, I have a
>>
>> Can't the patch be posted to the BTS and NMUed after two days if
>> there's no response (in general)?
>
> Yeah, but golly, sometimes there is no patch because the patch is
> blindingly obvious.

No, no, no.  Please not.  There's always a patch, and if it's only the
changelog entry.

It is extremely annoying if the first mail you find in your "package
foo" mail folder is the message by katie (or who is it?) that a bug you
didn't fix for one or the other reason has been fixed in an upload, but
you never heard that anybody intended to NMU, what they did, and maybe
why.

Yes, even "why", since although I know that some bug in a postrm script
is RC, I might not know that it breaks the autobuilders, and might
decide that I can as well first thoroughly test the other changes I made
meanwhile. 

Yes, "what they did", since even for obvious fixes there are different
ways to do it;  especially when you keep the package in a version
control system you want to either incorporate the NMUer's fix in HEAD,
or create a branch, so that you won't be surprised if you later get a
bug report with code you don't recall to have published (because you
haven't).  

> Or, worse yet, "please install the new upstream
> version" when that is necessary to fix an RC bug in some other
> package.

A new upstream version should usually not be NMUed; an NMU should keep
changes as minimal as possible.  If it cannot be avoided, then the patch
is even more important:  It shows the maintainer how intensely the NMUer
has studied the upstream changes, if and what changes to the packaging
were necessary, and so forth.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bits from the release team: the plans for etch

[Frank Küster]

Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> Paul TBBle Hampson <[EMAIL PROTECTED]> writes:
>
>> Didn't there used to be a delayed queue for NMUs to go into so that the
>> maintainer has time to nix it if neccessary? ^_^
>
> Sure, but at the moment, I only know one way to use dupload since the
> upload queues were changed.

There is a delayed queue:

http://www.mailarchives.org/list/debian-devel/msg/2004/03245

(I only used it last year, but I didn't hear that it stopped working).

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: udev and Logitech mouse applet

[Marco d'Itri]

reassign 334068 libsane
thanks

On Oct 17, Christopher Martin <[EMAIL PROTECTED]> wrote:

> On October 17, 2005 13:03, Marco d'Itri wrote:
> > > The problem seems to be that udev runs lmctl before the usbfs entry
> > > corresponding to your mouse has been created under /proc/bus/usb. The
> >
> > By design. The correct rule would be:
> >
> > BUS=="usb", SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c025", \
> > RUN+="/usr/bin/lmctl -8 --sms"
> 
> I doubt that switching from PROGRAM= to RUN+= will make a difference, as it 
> certainly didn't resolve the issue with kdebase. Perhaps you're not running 
OK, as it turns out I was half wrong: /proc/bus/ is not syncronous, so
scripts still need to wait (they may use the wait_for_file function from
/lib/hotplug/hotplug.functions). OTOH, RUN is still the correct keyword
to use, because PROGRAM has different semantics (and you must always use
+= unless you know better).

This looks like the same issue of #334068, which I am reassigning for
libsane (I'm sorry for not getting it right the first time).

> a modular kernel? I did notice that a homebrew everything-built-in kernel 
> did not suffer from this problem. I just took it for granted that the 
> udev/hotplug maintainer would be testing against a stock Debian kernel, or 
> at least something similarly modularized.
I need newer kernels before a debian package is available, and anyway I
will not use debian kernels again as long as they will break drivers
by removing uploadable firmwares.

> worked fine when hotplugged later. The wait loop fixed it. A rule like:
> 
> SYSFS{idProduct}=="0039", SYSFS{idVendor}=="045e", MODE="660", 
> GROUP="plugdev"
> 
> ...changes the permissions of /dev/input/ nodes instead of usbfs entries, 
> which isn't very helpful in this case.
Because the rule matches on many events, among them BUS=="usb".
The correct rule to change the /dev/bus/usb/ device permissions would
be:

SUBSYSTEM=="usb_device", SYSFS{idProduct}=="0039", SYSFS{idVendor}=="045e", \
GROUP="plugdev"

(660 is the default.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Query about LmBench

[animesh bhowmick]

Hi ,

I found LmBench in the Debian web site.

Is it free for usage?

I would like to run LmBench on the MIPS platform. Is
there any particular way of configuring it? We do not
have any native compiler or tools running on the
target MIPS platform.

In the following link,
http://packages.debian.org/unstable/admin/lmbench

I found a download for MIPS. Then I saw it is having a
.deb extension. How does one uncompress this?

Please furnish the above information.
Thanks and regards
Animesh




__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/


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